[JBoss JIRA] (DROOLS-1415) OOPath constraint bug4
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1415?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1415.
---------------------------------
Fix Version/s: 7.0.0.CR1
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/e256d9c844550d8df5a08d6f13e14...
> OOPath constraint bug4
> ----------------------
>
> Key: DROOLS-1415
> URL: https://issues.jboss.org/browse/DROOLS-1415
> Project: Drools
> Issue Type: Sub-task
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Fix For: 7.0.0.CR1
>
>
> {code:java}
> public static class TMFileSetQuater extends AbstractReactiveObject {
> private final String name;
> private final Set<TMFileWithParentObj> members = new ReactiveSet<TMFileWithParentObj>();
> public TMFileSetQuater(String name) {
> this.name = name;
> }
> public String getName() {
> return name;
> }
> public Set<TMFileWithParentObj> getFiles() {
> return members;
> }
> }
>
> @Test
> public void testWronglyMatchAlsoEqualsQuater() {
> String drl =
> "import org.drools.compiler.xpath.*;\n" +
> "import "+TMFileSetQuater.class.getCanonicalName()+";\n" +
> "global java.util.Set duplicateNames; \n" +
> "\n" +
> "rule DIFF_FILES_BUT_WITH_SAME_FILENAME when\n" +
> " $ic1 : TMFileWithParentObj( parent instanceof TMFileSetQuater ,\n" +
> " $curName : name, $curId : id, \n" +
> " $ic2: /parent{#TMFileSetQuater}/files{name == $curName, id != $curId } )\n" +
> "then\n" +
> " System.out.println( $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);
>
> TMFileSetQuater x = new TMFileSetQuater("X");
> TMFileWithParentObj file0 = new TMFileWithParentObj(0, "File0", 47, x);
> TMFileWithParentObj file1 = new TMFileWithParentObj(1, "File1", 47, x);
> TMFileWithParentObj file2 = new TMFileWithParentObj(2, "File0", 47, x);
> x.getFiles().addAll(Arrays.asList(new TMFileWithParentObj[]{file0, file1, file2}));
>
> ksession.insert( x );
> ksession.insert( file0 );
> ksession.insert( file1 );
> ksession.insert( file2 );
> 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
[JBoss JIRA] (DROOLS-1414) OOPath constraint bug3
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1414?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1414.
---------------------------------
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/e256d9c844550d8df5a08d6f13e14...
> OOPath constraint bug3
> ----------------------
>
> Key: DROOLS-1414
> URL: https://issues.jboss.org/browse/DROOLS-1414
> Project: Drools
> Issue Type: Sub-task
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
>
> {code:java}
> @Test
> public void testWronglyMatchAlsoEqualsTris() {
> String drl =
> "import org.drools.compiler.xpath.*;\n" +
> "global java.util.Set duplicateNames; \n" +
> "\n" +
> "rule DIFF_FILES_BUT_WITH_SAME_FILENAME when\n" +
> " $ic1 : TMFileWithParentObj( parent instanceof TMFileSet ,\n" +
> " $curName : name,\n" +
> " $ic2: /parent{#TMFileSet}/files{name == $curName, this != $ic1 } )\n" +
> "then\n" +
> " System.out.println( $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");
> TMFileWithParentObj file0 = new TMFileWithParentObj(0, "File0", 47, x);
> TMFileWithParentObj file1 = new TMFileWithParentObj(1, "File1", 47, x);
> TMFileWithParentObj file2 = new TMFileWithParentObj(2, "File0", 47, x);
> x.getFiles().addAll(Arrays.asList(new TMFile[]{file0, file1, file2}));
>
> ksession.insert( x );
> ksession.insert( file0 );
> ksession.insert( file1 );
> ksession.insert( file2 );
> 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
[JBoss JIRA] (DROOLS-1412) OOPath constraint bug1
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1412?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1412.
---------------------------------
Fix Version/s: 7.0.0.CR1
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/e256d9c844550d8df5a08d6f13e14...
> OOPath constraint bug1
> ----------------------
>
> Key: DROOLS-1412
> URL: https://issues.jboss.org/browse/DROOLS-1412
> Project: Drools
> Issue Type: Sub-task
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Fix For: 7.0.0.CR1
>
>
> {code:java}
> @Test
> public void testWronglyMatchAlsoEquals() {
> 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 )\n" +
> " TMFileSet( this == $dir1, $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
[JBoss JIRA] (WFLY-7916) Undertow listener wrong type INT/LONG
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7916?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved JBEAP-8389 to WFLY-7916:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7916 (was: JBEAP-8389)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: User Experience)
(was: Web (Undertow))
Target Release: (was: 7.1.0.GA)
Affects Version/s: (was: 7.1.0.DR10)
Affects Testing: (was: Regression)
> Undertow listener wrong type INT/LONG
> -------------------------------------
>
> Key: WFLY-7916
> URL: https://issues.jboss.org/browse/WFLY-7916
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Bogdan Sikora
> Assignee: Brian Stansberry
>
> Description of the "max-post-size" stays
> {noformat}
> "max-post-size" => {
> "type" => LONG,
> "description" => "The maximum size of a post that will be accepted, in bytes.",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "default" => 10485760L,
> "unit" => "BYTES",
> "min" => 1L,
> "max" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> {noformat}
> but when trying to set long value this error is printed.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-post-size, value=9223372036854775807)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0097: Wrong type for 'max-post-size'. Expected [INT] but was STRING. Couldn't convert \"9223372036854775807\" to [INT]",
> "rolled-back" => true,
> "response-headers" => {"process-state" => "reload-required"}
> }
> {noformat}
--
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 Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1416?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1416:
--------------------------------
Priority: Major (was: Blocker)
> 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-7153) Inconsistency of resources *-ssl-context in model vs. XSD
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7153?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7153:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Inconsistency of resources *-ssl-context in model vs. XSD
> ---------------------------------------------------------
>
> Key: WFLY-7153
> URL: https://issues.jboss.org/browse/WFLY-7153
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: user_experience
> Fix For: 11.0.0.Alpha1
>
>
> * in client-ssl-context there is attribute {{security-domain}} in XSD, which is not in model. In case of client-ssl-context this probably does not make sense and reaaly should't be in XSD, neither.
> * in both *-ssl-context there is provider in XSD and provider-loader in model. Sync it please. Probably possibility to specify both could be useful.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7153) Inconsistency of resources *-ssl-context in model vs. XSD
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7153?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7153:
-----------------------------------
Affects Version/s: (was: 11.0.0.Alpha1)
> Inconsistency of resources *-ssl-context in model vs. XSD
> ---------------------------------------------------------
>
> Key: WFLY-7153
> URL: https://issues.jboss.org/browse/WFLY-7153
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: user_experience
> Fix For: 11.0.0.Alpha1
>
>
> * in client-ssl-context there is attribute {{security-domain}} in XSD, which is not in model. In case of client-ssl-context this probably does not make sense and reaaly should't be in XSD, neither.
> * in both *-ssl-context there is provider in XSD and provider-loader in model. Sync it please. Probably possibility to specify both could be useful.
--
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 Kabir Khan (JIRA)
Kabir Khan created WFCORE-2217:
----------------------------------
Summary: 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