[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 reassigned DROOLS-1412:
-----------------------------------
Assignee: Mario Fusco (was: Matteo Mortari)
> 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
>
> {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, 5 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 reassigned DROOLS-1414:
-----------------------------------
Assignee: Mario Fusco (was: Matteo Mortari)
> 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, 5 months
[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 reassigned DROOLS-1415:
-----------------------------------
Assignee: Mario Fusco (was: Matteo Mortari)
> 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
>
> {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, 5 months
[JBoss JIRA] (WFLY-7915) CCME in WildFlyJobXmlResolver
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-7915?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-7915:
-------------------------------------
This seems odd. Each deployment should have their own {{WildFlyJobXmlResolver}} and the collection is only modified during initialization.
> CCME in WildFlyJobXmlResolver
> -----------------------------
>
> Key: WFLY-7915
> URL: https://issues.jboss.org/browse/WFLY-7915
> 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, 5 months
[JBoss JIRA] (WFCORE-2215) Unable to force replacement of deployment in domain with deploy <path> --force high level command
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2215?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-8387 to WFCORE-2215:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2215 (was: JBEAP-8387)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Affects Version/s: (was: 7.1.0.DR10)
Affects Testing: (was: Regression)
> Unable to force replacement of deployment in domain with deploy <path> --force high level command
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2215
> URL: https://issues.jboss.org/browse/WFCORE-2215
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Michal Jurc
> Assignee: Brian Stansberry
>
> The following failure is produced when trying to force replacement of deployments in JBoss EAP 7.1.0.DR10 with high level command:
> {code}[domain@localhost:9990 /] deploy ~/testing/eap/7.0.0/jboss-eap-7.0.0.GA-quickstarts/helloworld/target/jboss-helloworld.war --server-groups=main-server-group
> [domain@localhost:9990 /] deploy ~/testing/eap/7.0.0/jboss-eap-7.0.0.GA-quickstarts/helloworld/target/jboss-helloworld.war --force
> {"host-failure-descriptions" => {"hc1" => "WFLYDC0041: A slave domain controller cannot accept deployment content uploads"}}
> {code}
> This operation is referenced in community documentation: [Application deployment|https://docs.jboss.org/author/display/WFLY/Application+deployment]
> This operation works with JBoss EAP 7.0 and 6.4.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7322) LDAP referrals does not work in Elytron ldap-realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.... ]
Jan Kalina reopened WFLY-7322:
------------------------------
> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
> Key: WFLY-7322
> URL: https://issues.jboss.org/browse/WFLY-7322
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 11.0.0.Alpha1
>
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-804) LdapRealm - referral mode: direct verification + THROW mode
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-804?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina reopened ELY-804:
----------------------------
As reported in JBEAP-6450 , does not work - authentication is not done against context, where the user was found, but against the original context instead.
> LdapRealm - referral mode: direct verification + THROW mode
> ------------------------------------------------------------
>
> Key: ELY-804
> URL: https://issues.jboss.org/browse/ELY-804
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Realms
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 1.1.0.Beta17
>
>
> *1) Log in as referral user is still not possible.*
> Currently referral user can be found by ldap realm, but his password cannot be verified => log in is still not possible.
> There are two possible ways how to authenticate user in ldap realm:
> using direct verification - in this case after obtaining referral user, this referral user is used in LDAP bindRequest against original LDAP server (not referenced LDAP server) which results to invalid credentials bindResponse
> not using direct verification - in this case after obtaining referral user, this user is used as part of baseObject scope LDAP searchRequest for password attribute against original LDAP server (not referenced LDAP server) which results to noSuchObject searchResDone.
> Comment [1] says that you are able to log in as user of referred server. Can you please share your configuration? Since there is no related documentation, maybe I do something wrong in using/not using of direct verification.
> *2) Elytron does not handle THROW referral mode*
> In case when dir-context uses THROW referral-mode then com.sun.jndi.ldap.LdapReferralException is not caught in Elytron (which is LDAP client) and is thrown to integration tier which also does not handle it, e.g. in case when ldap-realm is used for authentication to application, then it results to status code 500 returned to the application.
> [1] https://issues.jboss.org/browse/WFLY-7322?focusedCommentId=13307815&page=...
> ( Requested in https://issues.jboss.org/browse/JBEAP-6450?focusedCommentId=13323387#comm... )
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-804) LdapRealm - referral mode: direct verification + THROW mode
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-804?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-804:
---------------------------
Fix Version/s: 1.1.0.Beta17
> LdapRealm - referral mode: direct verification + THROW mode
> ------------------------------------------------------------
>
> Key: ELY-804
> URL: https://issues.jboss.org/browse/ELY-804
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Realms
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 1.1.0.Beta17
>
>
> *1) Log in as referral user is still not possible.*
> Currently referral user can be found by ldap realm, but his password cannot be verified => log in is still not possible.
> There are two possible ways how to authenticate user in ldap realm:
> using direct verification - in this case after obtaining referral user, this referral user is used in LDAP bindRequest against original LDAP server (not referenced LDAP server) which results to invalid credentials bindResponse
> not using direct verification - in this case after obtaining referral user, this user is used as part of baseObject scope LDAP searchRequest for password attribute against original LDAP server (not referenced LDAP server) which results to noSuchObject searchResDone.
> Comment [1] says that you are able to log in as user of referred server. Can you please share your configuration? Since there is no related documentation, maybe I do something wrong in using/not using of direct verification.
> *2) Elytron does not handle THROW referral mode*
> In case when dir-context uses THROW referral-mode then com.sun.jndi.ldap.LdapReferralException is not caught in Elytron (which is LDAP client) and is thrown to integration tier which also does not handle it, e.g. in case when ldap-realm is used for authentication to application, then it results to status code 500 returned to the application.
> [1] https://issues.jboss.org/browse/WFLY-7322?focusedCommentId=13307815&page=...
> ( Requested in https://issues.jboss.org/browse/JBEAP-6450?focusedCommentId=13323387#comm... )
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months