[JBoss JIRA] (WFCORE-2219) Ability to turn off boot time capability resolution leniency in admin-only mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2219?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2219:
-------------------------------------
Description:
Currently boot is lenient about broken capability requirements during admin-only boot. We need a way to turn this off.
The current behavior is a fine default, as it allows users to boot a broken config in --admin-only and then fix the config. Without this the user is forced to rely on xml editing.
But there are other use cases for admin-only, for example in automated provisioning systems or testing systems, where the user can quite reasonably want a broken config to immediately generate a boot failure, as the automated system is not designed to handle incorrect initial input.
was:
Currently boot is lenient about broken capability requirements during admin-only boot. We need a way to turn this off.
The current behavior is a fine default, as it allows users to boot a broken config in --admin-only and then fix the config. Without this the user is forced to rely on xml editing.
But there are other use cases for admin-only, for example in automated provisioning systems or testing systems, where the user can quite reasonable want a broken config to immediately generate a boot failure, as the automated system is not designed to handle incorrect initial input.
> Ability to turn off boot time capability resolution leniency in admin-only mode
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2219
> URL: https://issues.jboss.org/browse/WFCORE-2219
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
>
> Currently boot is lenient about broken capability requirements during admin-only boot. We need a way to turn this off.
> The current behavior is a fine default, as it allows users to boot a broken config in --admin-only and then fix the config. Without this the user is forced to rely on xml editing.
> But there are other use cases for admin-only, for example in automated provisioning systems or testing systems, where the user can quite reasonably want a broken config to immediately generate a boot failure, as the automated system is not designed to handle incorrect initial input.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2219) Ability to turn off boot time capability resolution leniency in admin-only mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2219?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2219:
------------------------------------------
If this is done via a command line switch, possibly the same switch could drive whether boot is lenient in non-admin-only mode about Stage.RUNTIME failures.
--boot-validation=LENIENT | STRICT
We're currently LENIENT in both admin-only and normal mode, so it's possible to add this without breaking either thing.
I don't know if it's wise to use a single param to control two slightly different things though. But if we want to, then we should use it for both from the start, otherwise we introduce a behavior change when we bring it in for the 2nd behavior.
> Ability to turn off boot time capability resolution leniency in admin-only mode
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2219
> URL: https://issues.jboss.org/browse/WFCORE-2219
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
>
> Currently boot is lenient about broken capability requirements during admin-only boot. We need a way to turn this off.
> The current behavior is a fine default, as it allows users to boot a broken config in --admin-only and then fix the config. Without this the user is forced to rely on xml editing.
> But there are other use cases for admin-only, for example in automated provisioning systems or testing systems, where the user can quite reasonable want a broken config immediately generate an boot failure, as the automated system is not designed to handle incorrect initial input.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2219) Ability to turn off boot time capability resolution leniency in admin-only mode
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2219:
----------------------------------------
Summary: Ability to turn off boot time capability resolution leniency in admin-only mode
Key: WFCORE-2219
URL: https://issues.jboss.org/browse/WFCORE-2219
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Currently boot is lenient about broken capability requirements during admin-only boot. We need a way to turn this off.
The current behavior is a fine default, as it allows users to boot a broken config in --admin-only and then fix the config. Without this the user is forced to rely on xml editing.
But there are other use cases for admin-only, for example in automated provisioning systems or testing systems, where the user can quite reasonable want a broken config immediately generate an boot failure, as the automated system is not designed to handle incorrect initial input.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2218) Ability to ask testrunner ServerController to wait for server process exit and get the exit code
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2218?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2218:
------------------------------------------
Perhaps this in ServerController
{code}
/**
* Spawns a thread to execute a given {@code restartTrigger} task and then starts a new server
* process once the existing server exits with the usual restart exit code.
*
* @param restartTrigger a runnable that will somehow result in the existing server process exiting with the
* restart exit code. Cannot be {@code null}
* @param timeout maximum time in ms to wait for the server process to exit
*
* @throws RuntimeException if {@code restartTrigger} throws an exception
* @throws AssertionError if {@code restartTrigger} throws an AssertionError, if the server does not stop within
* {@code timeout} ms, or if the server's exit code is not the one expected.
*/
public void handleServerRestart(Runnable restartTrigger, long timeout);
{code}
> Ability to ask testrunner ServerController to wait for server process exit and get the exit code
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2218
> URL: https://issues.jboss.org/browse/WFCORE-2218
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Test Suite
> Reporter: Brian Stansberry
>
> Imagine testing the shutdown --restart CLI command in a manualmode test.
> The standalone.sh script is not used so the restart won't work, as the restart logic is in the script. But the test itself could handle the restart part if the ServerController would let it know when the server process is stopped and what the exit code was.
> So,
> 1) test spawns a thread to do shutdown --restart in the CLI
> 2) test waits for server to stop, confirms correct exit code
> 3) test starts the server again
> 4) thread doing the shutdown --restart moves on since the server starts again
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2218) Ability to ask testrunner ServerController to wait for server process exit and get the exit code
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2218:
----------------------------------------
Summary: Ability to ask testrunner ServerController to wait for server process exit and get the exit code
Key: WFCORE-2218
URL: https://issues.jboss.org/browse/WFCORE-2218
Project: WildFly Core
Issue Type: Enhancement
Components: Test Suite
Reporter: Brian Stansberry
Imagine testing the shutdown --restart CLI command in a manualmode test.
The standalone.sh script is not used so the restart won't work, as the restart logic is in the script. But the test itself could handle the restart part if the ServerController would let it know when the server process is stopped and what the exit code was.
So,
1) test spawns a thread to do shutdown --restart in the CLI
2) test waits for server to stop, confirms correct exit code
3) test starts the server again
4) thread doing the shutdown --restart moves on since the server starts again
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2217) ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2217:
------------------------------------------
"I'd hazard a guess and say that the subsystem tests are aiming for good coverage, and so might be setting stuff which would fail validation e.g. of Alternatives."
Removing the ability to do this fairly easily is the big concern. A big thing the subsystem tests do is set everything and then confirm it goes through the marshal/re-parse processing correctly.
I think it's valid to ask test authors to configure something to turn on that leniency but we should think about how to do that nicely, as configuring subsystem tests is already quite painful.
> ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2217
> URL: https://issues.jboss.org/browse/WFCORE-2217
> Project: WildFly Core
> Issue Type: Component Upgrade
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha16
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha20, 4.0.0.Beta1
>
>
> During a normal server boot ValidationStepHandler gets called. But during a core-model-/subsystem tests it does not get called on boot. The issue is that in these tests bootOperations.postExtensionOps are null, so the if block at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src... which contains the validation logic at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src... does not get called.
> The fix is quite simple:
> {code}
> diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> index 4a6cc7c..d8e1911 100644
> --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController {
> }
>
> resultAction = postExtContext.executeOperation();
> + }
>
> - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) {
> - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> - Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> - Resource root = managementModel.get().getRootResource();
> - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> -
> - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> - extraValidationStepHandler, partialModel, securityIdentitySupplier);
> - validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> - resultAction = validateContext.executeOperation();
> - }
> + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) {
> + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> + Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> + Resource root = managementModel.get().getRootResource();
> + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> +
> + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> + extraValidationStepHandler, partialModel, securityIdentitySupplier);
> + validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> + resultAction = validateContext.executeOperation();
> }
>
> return resultAction == OperationContext.ResultAction.KEEP;
> {code}
> but changing this and trying to run the widlfly-core tests causes failures in the remoting subsystem and loads in the core-model-tests. There are bound to be more in the subsystems in full.
> I'd hazard a guess and say that the subsystem tests are aiming for good coverage, and so might be setting stuff which would fail validation e.g. of Alternatives.
> For core model tests it is complaining about things like missing management-xxx-versions in the model, default interfaces in socket binding groups and a lot of things like that. In a lot of cases the xml used in the tests uses minimum information to set up things for what is needed. WIP for the core model tests is:
> {code}
> diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> index 4a6cc7c..d8e1911 100644
> --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController {
> }
>
> resultAction = postExtContext.executeOperation();
> + }
>
> - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) {
> - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> - Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> - Resource root = managementModel.get().getRootResource();
> - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> -
> - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> - extraValidationStepHandler, partialModel, securityIdentitySupplier);
> - validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> - resultAction = validateContext.executeOperation();
> - }
> + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) {
> + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> + Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> + Resource root = managementModel.get().getRootResource();
> + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> +
> + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> + extraValidationStepHandler, partialModel, securityIdentitySupplier);
> + validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> + resultAction = validateContext.executeOperation();
> }
>
> return resultAction == OperationContext.ResultAction.KEEP;
> {code}
> So although the fix is simple, the fallout of this is quite big.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2214) The http-management management interface should not be deprecated
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2214?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-2214.
--------------------------------------
Resolution: Won't Do
We deprecated it in EAP 6.4 and the reasons we did still apply. At some point this may become a subsystem resource.
TBH I regret deprecating it then as it seemed a bit early, but now that we've done it it seems a bit pointless to remove it just to restore it later.
> The http-management management interface should not be deprecated
> -----------------------------------------------------------------
>
> Key: WFCORE-2214
> URL: https://issues.jboss.org/browse/WFCORE-2214
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Josef Cacek
> Assignee: Brian Stansberry
> Labels: user_experience
>
> The *http-management* management interface is marked as deprecated. Which is IMO wrong.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (DROOLS-1416) DRL Dumper Not Printing the content of ConditionalBranch
by Siyad Theyparambil Mohammed (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1416?page=com.atlassian.jira.plugi... ]
Siyad Theyparambil Mohammed commented on DROOLS-1416:
-----------------------------------------------------
HI [~mfusco]
Could you please let us know if we have ConditionalBranchDescr support in drl.mvel ?
> DRL Dumper Not Printing the content of ConditionalBranch
> --------------------------------------------------------
>
> Key: DROOLS-1416
> URL: https://issues.jboss.org/browse/DROOLS-1416
> Project: Drools
> Issue Type: Bug
> Components: tools
> Affects Versions: 6.4.0.Final
> Reporter: Siyad Theyparambil Mohammed
> Assignee: Mario Fusco
>
> While trying to use conditionalbranch api for handling multiple if-then blocks, the DRL dumper is not printing the content we have used for conditionalbranch. Please find the sample code below and the restuls
> *+Code+*
> PackageDescr pkg = DescrFactory.newPackage()
> .name( "org.drools.compiler" )
> .newRule().name( "test" )
> .lhs()
> .pattern("Cheese").constraint( "type == \"stilton\"" ).end()
> .conditionalBranch()
> .condition().constraint("price < 10").end()
> .consequence().name("c1").end()
> .end()
> .pattern("Cheese").constraint( "type == \"cheddar\"" ).end()
> .conditionalBranch()
> .condition().constraint("price > 10").end()
> .consequence().name("c2").end()
> .end()
> .end()
> .rhs( "// do something" )
> .namedRhs( "c1", "// do something else\n" )
> .end()
> .getDescr();
>
> return new DrlDumper().dump( pkg );
> *+Output+*
> package org.drools.compiler
> rule "test"
> when
> Cheese( type == "stilton" )
>
> Cheese( type == "cheddar" )
>
> then
> // do something
> then[c1]
> // do something else
> end
> In the above example the content "price < 10" and "price > 10" which we have used for conditionalBranch is not getting printed. On further investigation we found the drl.mvel template does not have the import org.drools.compiler.lang.descr.ConditionalBranchDescr.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7917) CCME in WildFlyJobXmlResolver
by James Perkins (JIRA)
James Perkins created WFLY-7917:
-----------------------------------
Summary: CCME in WildFlyJobXmlResolver
Key: WFLY-7917
URL: https://issues.jboss.org/browse/WFLY-7917
Project: WildFly
Issue Type: Bug
Components: Batch
Reporter: Tomaz Cerar
Assignee: James Perkins
When running on JDK9-ea there are ConncurrentModificationExceptions happening in WildFlyJobXmlResolver
Problem can happen also on JDK8 but it looks like it is easier to reproduce on JDK9.
{code}
Caused by: java.util.ConcurrentModificationException at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1138)
at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.addJob(WildFlyJobXmlResolver.java:290)
at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.init(WildFlyJobXmlResolver.java:280)
at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.create(WildFlyJobXmlResolver.java:231)
at org.wildfly.extension.batch.jberet.deployment.WildFlyJobXmlResolver.forDeployment(WildFlyJobXmlResolver.java:110)
at org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentProcessor.deploy(BatchEnvironmentProcessor.java:77)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
{code}
see https://ci.wildfly.org/viewLog.html?buildId=41982&tab=buildResultsDiv&bui... for failures
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (DROOLS-1413) OOPath constraint bug2
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1413?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1413.
---------------------------------
Fix Version/s: 7.0.0.CR1
Resolution: Won't Fix
More than one oopath is not allowed in the same pattern. This commit https://github.com/droolsjbpm/drools/commit/e256d9c844550d8df5a08d6f13e14... now generates a compile time error.
> OOPath constraint bug2
> ----------------------
>
> Key: DROOLS-1413
> URL: https://issues.jboss.org/browse/DROOLS-1413
> Project: Drools
> Issue Type: Sub-task
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Fix For: 7.0.0.CR1
>
>
> {code:java}
> @Test
> public void testWronglyMatchAlsoEqualsBis() {
> String drl =
> "import org.drools.compiler.xpath.*;\n" +
> "global java.util.Set duplicateNames; \n" +
> "\n" +
> "rule DIFF_FILES_BUT_WITH_SAME_FILENAME when\n" +
> " $dir1 : TMFileSet( $ic1 : /files, $ic2 : /files{name == $ic1.name}, $ic1 != $ic2 )\n" +
> "then\n" +
> " System.out.println( $dir1 + \".: \" + $ic1 + \" \" + $ic2 );\n" +
> " duplicateNames.add( $ic1.getName() );\n" +
> "end\n";
> KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
> .build()
> .newKieSession();
>
> Set duplicateNames = new HashSet();
> ksession.setGlobal("duplicateNames", duplicateNames);
>
> TMFileSet x = new TMFileSet("X");
> TMFile file0 = new TMFile("File0", 47);
> TMFile file1 = new TMFile("File1", 47);
> TMFile file2 = new TMFile("File0", 47);
> x.getFiles().addAll(Arrays.asList(new TMFile[]{file0, file1, file2}));
>
> ksession.insert(x);
> ksession.fireAllRules();
>
> assertTrue( duplicateNames.contains("File0") );
> assertFalse( duplicateNames.contains("File1") );
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months