[JBoss JIRA] (ELY-1851) Elytron ldaps realm fails if a referral is returned inside a search
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1851?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated ELY-1851:
----------------------------------
Fix Version/s: 1.6.8.Final
(was: 1.6.7.Final)
> Elytron ldaps realm fails if a referral is returned inside a search
> -------------------------------------------------------------------
>
> Key: ELY-1851
> URL: https://issues.redhat.com/browse/ELY-1851
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.6.3.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
> Fix For: 1.6.8.Final
>
>
> Elytron LdapRealm fails to follow a referral when ldaps is used (the {{ThreadLocalSSLSocketFactory}} is not set).
> With a configuration similar to this one ({{memberOf}} is used to locate groups):
> {code:xml}
> <ldap-realm name="ldap-realm" dir-context="ldap-dir-context" direct-verification="true">
> <identity-mapping rdn-identifier="sAMAccountName" use-recursive-search="true" search-base-dn="DC=redhat,DC=com">
> <attribute-mapping>
> <attribute reference="memberOf" from="cn" to="Roles" role-recursion="3"/>
> </attribute-mapping>
> </identity-mapping>
> </ldap-realm>
> ...
> <dir-context name="ldap-dir-context" url="ldaps://ldap.redhat.com:636" principal="cn=Administrator,cn=Users,DC=redhat,DC=com" referral-mode="FOLLOW" ssl-context="ldaps-context">
> <credential-reference store="credstore" alias="ldap_password"/>
> </dir-context>
> {code}
> If we have a group (or user) which contains a {{memberOf}} of another ldap, something like the following:
> {noformat}
> dn: CN=group-with-external-members,OU=Groups,DC=redhat,DC=com
> ...
> memberOf: CN=group-in-another-domain,OU=Groups,DC=lab,DC=redhat,DC=com
> {noformat}
> The following exception is thrown when a referral is returned for a group that is inside another ldapserver of the forest:
> {noformat}
> TRACE [org.jboss.remoting.remote.server] (management task-1) Server sending authentication rejected: java.lang.RuntimeException: ELY01079: ldap-realm realm failed to obtain attributes for entry [CN=group-with-external-members,OU=Groups,DC=redhat,DC=com]
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributesFromSearch(LdapSecurityRealm.java:808)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$4(LdapSecurityRealm.java:768)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.forEachAttributeValue(LdapSecurityRealm.java:841)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:766)
> at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1321)
> at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractAttributes(LdapSecurityRealm.java:828)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributes(LdapSecurityRealm.java:754)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getAttributes(LdapSecurityRealm.java:516)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getAuthorizationIdentity(LdapSecurityRealm.java:497)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1923)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1952)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:509)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:489)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:872)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
> at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:60)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
> at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:146)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:59)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:486)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:942)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: ELY01108: ldap-realm realm identity search failed
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.search(LdapSecurityRealm.java:1141)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributesFromSearch(LdapSecurityRealm.java:797)
> ... 46 more
> Caused by: javax.naming.CommunicationException: ldap.lab.redhat.com:636 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without ThreadLocalSSLSocketFactory thread local setting]
> at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:96)
> at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:151)
> at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1861)
> at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769)
> at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1786)
> at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:418)
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:396)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:297)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:297)
> at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.search(DelegatingLdapContext.java:335)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.searchWithPagination(LdapSecurityRealm.java:1161)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.search(LdapSecurityRealm.java:1038)
> ... 47 more
> Caused by: java.lang.IllegalStateException: ELY04025: DirContext tries to connect without ThreadLocalSSLSocketFactory thread local setting
> at org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory.getDefault(ThreadLocalSSLSocketFactory.java:46)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:296)
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:215)
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1609)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:151)
> at com.sun.jndi.url.ldap.ldapURLContextFactory.getObjectInstance(ldapURLContextFactory.java:52)
> at org.jboss.as.naming.context.ObjectFactoryBuilder$ReferenceUrlContextFactoryWrapper.getObjectInstance(ObjectFactoryBuilder.java:293)
> at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:300)
> at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:119)
> ... 58 more
> {noformat}
> The reason seems to be that the {{ThreadLocalSSLSocketFactory}} is not set when doing a search, so, if a referral is returned the new search created inside the current one has no access to the {{SSLSocketFactory}} in the thread local.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (ELY-1954) Submission for "j_security_check" login does not work if URL has no trailing slash
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1954?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated ELY-1954:
----------------------------------
Fix Version/s: 1.6.7.Final
1.10.7.CR1
> Submission for "j_security_check" login does not work if URL has no trailing slash
> ----------------------------------------------------------------------------------
>
> Key: ELY-1954
> URL: https://issues.redhat.com/browse/ELY-1954
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Reporter: Wolfgang Knauf
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.6.7.Final, 1.10.7.CR1, 1.11.4.Final
>
> Attachments: Security.ear, configure.cli, restore-configuration.cli
>
>
> Attached file "Security.ear" contains a web application with a single jsp page "index.jsp" and form based login, which is secured by a Database Identity Store (Elytron).
> When calling the root URL of the webapp without specifiying any page and {color:red}*no*{color} trailing slash (http://localhost:8080/SecurityWeb), on WildFly 11 the login form is shown, and then the welcome file "index.jsp" is shown.
> On WildFly 19, the login form is shown, and after successful login, there is an error message "404 - Not Found", and the URL in the adress bar changes to http://localhost:8080/j_security_check
> It works if the URL is "http://localhost:8080/SecurityWeb/" (trailing slash). It seems WildFly 11 appends the "/" automatically when redirecting to the login form, while WildFly 19 keeps this URL.
> To run the sample, you have to add the Elytron config - the script "configure.cli" can be used for this:
> jboss-cli.bat --file=path_to\configure.cli
> The script "restore-configuration.cli" undoes this configuration.
> Username/Password are e.g. "admin"/"admin" - the sample creates a user table based on an ejb and "import.sql" inserts users.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (DROOLS-4461) Use date picker for LocalDate
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4461?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-4461:
--------------------------------
Description:
We should use the date picker for LocalDate like we do for Date.
h2. Acceptance test
- Guided rule condition (/)
- Guided rule action (/)
- Guided rule template condition (/)
- Guided rule template action (/)
- Guided decision table simple condition (/)
- Guided decision table BRL condition (/)
- Guided decision table simple action (/)
- Guided decision table BRL action (/)
was:
We should use the date picker for LocalDate like we do for Date.
h2. Acceptance test
- Guided rule condition (/)
- Guided rule action (/)
- Guided rule template condition (/)
- Guided rule template action (/)
- Guided decision table simple condition (x)
- Guided decision table BRL condition (x)
- Guided decision table simple action (x)
- Guided decision table BRL action (x)
> Use date picker for LocalDate
> -----------------------------
>
> Key: DROOLS-4461
> URL: https://issues.redhat.com/browse/DROOLS-4461
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor, Guided Rule Editor, Test Scenarios Editor
> Reporter: Toni Rikkola
> Assignee: Jozef Marko
> Priority: Major
> Labels: drools-tools
>
> We should use the date picker for LocalDate like we do for Date.
> h2. Acceptance test
> - Guided rule condition (/)
> - Guided rule action (/)
> - Guided rule template condition (/)
> - Guided rule template action (/)
> - Guided decision table simple condition (/)
> - Guided decision table BRL condition (/)
> - Guided decision table simple action (/)
> - Guided decision table BRL action (/)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (WFLY-9129) Setting env var SECMGR=true no longer works
by Lukas Vydra (Jira)
[ https://issues.redhat.com/browse/WFLY-9129?page=com.atlassian.jira.plugin... ]
Lukas Vydra reassigned WFLY-9129:
---------------------------------
Assignee: Lukas Vydra
> Setting env var SECMGR=true no longer works
> -------------------------------------------
>
> Key: WFLY-9129
> URL: https://issues.redhat.com/browse/WFLY-9129
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Affects Versions: 10.0.0.Final, 10.1.0.Final, 11.0.0.Alpha1
> Reporter: r searls
> Assignee: Lukas Vydra
> Priority: Major
>
> Setting env var SECMGR=true is suppose to enable the security manager.
> It is not working. I've tried the following and none of them enable
> the security manager.
> export SECMGR=true;
> on the cmd-line -DSECMGR=true
> edit bin/standalone.conf and uncomment line SECMGR="true"
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (DROOLS-5422) Fix DMN-PMML integration/managed fields
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5422?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5422:
-------------------------------------
Description:
>From [Output|[http://dmg.org/pmml/v4-4/Output.html]] documentation:
"If present, the attribute {{targetField}} must refer either to a {{MiningField}} of usage type {{target}} or a field described in {{Targets}} element. {{targetField}} is a required attribute in case the model has multiple target fields."
"predictedValue
Select the raw predicted value. More than one OutputField element can have the predictedValue feature only if the model predicts more than one field. Details can be found in the description of the individual models."
>From [MiningSchema|[http://dmg.org/pmml/v4-4/MiningSchema.html]] documentation:
"*predicted*: field whose value is predicted by the model. As of PMML 4.2, this is deprecated and it has been replaced by the usage type {{target}}."
So, _predicted_ field(s) is/are the one(s) defined as "_target/predicted_" inside _MiningSchema_ or the one(s) defined inside [Targets|[http://dmg.org/pmml/v4-4/Targets.html]] element.
_Output_ has to be considered as _additional_ results; it does not _necessarily_ contains the _target/predicted_ value; *but* the _target/predicted_ value should always be returned.
Currently, DMN (see DMNKiePMMLInvocationEvaluator as example) implement the following algorithm:
1) if "_Output_" element is present, it only manage it (ignores _MiningSchema_ fields)
2) if "_Output_" element is not present, it retrieves "_target_" from _MiningSchema_.
This approach has the following issues
1) it is not mandatory to have the "_target/predicted_" field referenced inside the "_Output_" element; but with the current implementation, the user is "_forced_" to duplicate target reference inside "_Output_" if s/he wants additional outputs from model
2) it completely ignores "_Targets_" element
With this PR, DMN will manage both the _Output_ elements (if present) and all the _target/predicted_ fields, regardless of where/how they are defined.
If such _target/predicted_ fields is/are referred *also* in Output element, only the one(s) inside _Output_ will be managed.
If _Output_ does not define "_target/predicted_" _OutputField_(s), the one(s) from _MiningSchema_ or _Targets_ will be managed.
was:
>From [Output|[http://dmg.org/pmml/v4-4/Output.html]] documentation:
"If present, the attribute {{targetField}} must refer either to a {{MiningField}} of usage type {{target}} or a field described in {{Targets}} element. {{targetField}} is a required attribute in case the model has multiple target fields."
"predictedValue
Select the raw predicted value. More than one OutputField element can have the predictedValue feature only if the model predicts more than one field. Details can be found in the description of the individual models."
>From [MiningSchema|[http://dmg.org/pmml/v4-4/MiningSchema.html]] documentation:
"*predicted*: field whose value is predicted by the model. As of PMML 4.2, this is deprecated and it has been replaced by the usage type {{target}}."
So, _predicted_ field(s) is/are the one(s) defined as "_target/predicted_" inside _MiningSchema_ or the one(s) defined inside [Targets|[http://dmg.org/pmml/v4-4/Targets.html]] element.
_Output_ has to be considered as _additional_ results; it does not _necessarily_ contains the _target/predicted_ value; *but* the _target/predicted_ value should always be returned.
Currently, DMN (see DMNKiePMMLInvocationEvaluator as example) implement the following algorithm:
1) if "_Output_" element is present, it only manage it (ignores _MiningSchema_ fields)
2) if "_Output_" element is not present, it retrieves "_target_" from _MiningSchema_.
This approach has the following issues
1) it is not mandatory to have the "_target/predicted_" field referenced inside the "_Output_" element; but with the current implementation, the user is "_forced_" to duplicate target reference inside "_Output_" if s/he wants additional outputs from model
2) it completely ignores "_Targets_" element
With this PR, DMN will manage both the _Output_ elements (if present) and all the _target/predicted_ fields, regardless of where/how they are defined.
If such _target/predicted_ fields is/are referred *also* in Output element, only the one(s) inside _Output_ will be managed.
If _Output_ does not define "t_arget/predicted_" _OutputField_(s), the one(s) from _MiningSchema_ or _Targets_ will be managed.
> Fix DMN-PMML integration/managed fields
> ---------------------------------------
>
> Key: DROOLS-5422
> URL: https://issues.redhat.com/browse/DROOLS-5422
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
>
> From [Output|[http://dmg.org/pmml/v4-4/Output.html]] documentation:
> "If present, the attribute {{targetField}} must refer either to a {{MiningField}} of usage type {{target}} or a field described in {{Targets}} element. {{targetField}} is a required attribute in case the model has multiple target fields."
> "predictedValue
> Select the raw predicted value. More than one OutputField element can have the predictedValue feature only if the model predicts more than one field. Details can be found in the description of the individual models."
> From [MiningSchema|[http://dmg.org/pmml/v4-4/MiningSchema.html]] documentation:
> "*predicted*: field whose value is predicted by the model. As of PMML 4.2, this is deprecated and it has been replaced by the usage type {{target}}."
>
> So, _predicted_ field(s) is/are the one(s) defined as "_target/predicted_" inside _MiningSchema_ or the one(s) defined inside [Targets|[http://dmg.org/pmml/v4-4/Targets.html]] element.
>
> _Output_ has to be considered as _additional_ results; it does not _necessarily_ contains the _target/predicted_ value; *but* the _target/predicted_ value should always be returned.
>
> Currently, DMN (see DMNKiePMMLInvocationEvaluator as example) implement the following algorithm:
> 1) if "_Output_" element is present, it only manage it (ignores _MiningSchema_ fields)
> 2) if "_Output_" element is not present, it retrieves "_target_" from _MiningSchema_.
> This approach has the following issues
> 1) it is not mandatory to have the "_target/predicted_" field referenced inside the "_Output_" element; but with the current implementation, the user is "_forced_" to duplicate target reference inside "_Output_" if s/he wants additional outputs from model
> 2) it completely ignores "_Targets_" element
> With this PR, DMN will manage both the _Output_ elements (if present) and all the _target/predicted_ fields, regardless of where/how they are defined.
>
> If such _target/predicted_ fields is/are referred *also* in Output element, only the one(s) inside _Output_ will be managed.
> If _Output_ does not define "_target/predicted_" _OutputField_(s), the one(s) from _MiningSchema_ or _Targets_ will be managed.
>
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (DROOLS-5422) Fix DMN-PMML integration/managed fields
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5422?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5422:
-------------------------------------
Description:
>From [Output|[http://dmg.org/pmml/v4-4/Output.html]] documentation:
"If present, the attribute {{targetField}} must refer either to a {{MiningField}} of usage type {{target}} or a field described in {{Targets}} element. {{targetField}} is a required attribute in case the model has multiple target fields."
"predictedValue
Select the raw predicted value. More than one OutputField element can have the predictedValue feature only if the model predicts more than one field. Details can be found in the description of the individual models."
>From [MiningSchema|[http://dmg.org/pmml/v4-4/MiningSchema.html]] documentation:
"*predicted*: field whose value is predicted by the model. As of PMML 4.2, this is deprecated and it has been replaced by the usage type {{target}}."
So, _predicted_ field(s) is/are the one(s) defined as "_target/predicted_" inside _MiningSchema_ or the one(s) defined inside [Targets|[http://dmg.org/pmml/v4-4/Targets.html]] element.
_Output_ has to be considered as _additional_ results; it does not _necessarily_ contains the _target/predicted_ value; *but* the _target/predicted_ value should always be returned.
Currently, DMN (see DMNKiePMMLInvocationEvaluator as example) implement the following algorithm:
1) if "_Output_" element is present, it only manage it (ignores _MiningSchema_ fields)
2) if "_Output_" element is not present, it retrieves "_target_" from _MiningSchema_.
This approach has the following issues
1) it is not mandatory to have the "_target/predicted_" field referenced inside the "_Output_" element; but with the current implementation, the user is "_forced_" to duplicate target reference inside "_Output_" if s/he wants additional outputs from model
2) it completely ignores "_Targets_" element
With this PR, DMN will manage both the _Output_ elements (if present) and all the _target/predicted_ fields, regardless of where/how they are defined.
If such _target/predicted_ fields is/are referred *also* in Output element, only the one(s) inside _Output_ will be managed.
If _Output_ does not define "t_arget/predicted_" _OutputField_(s), the one(s) from _MiningSchema_ or _Targets_ will be managed.
was:
>From [Output|[http://dmg.org/pmml/v4-4/Output.html]] documentation:
"If present, the attribute {{targetField}} must refer either to a {{MiningField}} of usage type {{target}} or a field described in {{Targets}} element. {{targetField}} is a required attribute in case the model has multiple target fields."
"predictedValue
Select the raw predicted value. More than one OutputField element can have the predictedValue feature only if the model predicts more than one field. Details can be found in the description of the individual models."
>From [MiningSchema|[http://dmg.org/pmml/v4-4/MiningSchema.html]] documentation:
"*predicted*: field whose value is predicted by the model. As of PMML 4.2, this is deprecated and it has been replaced by the usage type {{target}}."
So, _predicted_ field(s) is/are the one(s) defined as "_target/predicted_" inside _MiningSchema_ or the one(s) defined inside [Targets|[http://dmg.org/pmml/v4-4/Targets.html]] element.
Output have to be considered as _additional_ results; it does not _necessarily_ contains the _target/predicted_ value; *but* the _target/predicted_ value should always be returned.
Currently, DMN (see DMNKiePMMLInvocationEvaluator as example) implement the following algorithm:
1) if "_Output_" element is present, it only manage it (ignores _MiningSchema_ fields)
2) if "_Output_" element is not present, it retrieves "_target_" from _MiningSchema_.
This approach has the following issues
1) it is not mandatory to have the "_target/predicted_" field referenced inside the "_Output_" element; but with the current implementation, the user is "_forced_" to duplicate target reference inside "_Output_" if s/he wants additional outputs from model
2) it completely ignores "_Targets_" element
With this PR, DMN will manage both the _Output_ elements (if present) and all the _target/predicted_ fields, regardless of where/how they are defined.
If such _target/predicted_ fields is/are referred *also* in Output element, only the one(s) inside _Output_ will be managed.
If _Output_ does not define "t_arget/predicted_" _OutputField_(s), the one(s) from _MiningSchema_ or _Targets_ will be managed.
> Fix DMN-PMML integration/managed fields
> ---------------------------------------
>
> Key: DROOLS-5422
> URL: https://issues.redhat.com/browse/DROOLS-5422
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
>
> From [Output|[http://dmg.org/pmml/v4-4/Output.html]] documentation:
> "If present, the attribute {{targetField}} must refer either to a {{MiningField}} of usage type {{target}} or a field described in {{Targets}} element. {{targetField}} is a required attribute in case the model has multiple target fields."
> "predictedValue
> Select the raw predicted value. More than one OutputField element can have the predictedValue feature only if the model predicts more than one field. Details can be found in the description of the individual models."
> From [MiningSchema|[http://dmg.org/pmml/v4-4/MiningSchema.html]] documentation:
> "*predicted*: field whose value is predicted by the model. As of PMML 4.2, this is deprecated and it has been replaced by the usage type {{target}}."
>
> So, _predicted_ field(s) is/are the one(s) defined as "_target/predicted_" inside _MiningSchema_ or the one(s) defined inside [Targets|[http://dmg.org/pmml/v4-4/Targets.html]] element.
>
> _Output_ has to be considered as _additional_ results; it does not _necessarily_ contains the _target/predicted_ value; *but* the _target/predicted_ value should always be returned.
>
> Currently, DMN (see DMNKiePMMLInvocationEvaluator as example) implement the following algorithm:
> 1) if "_Output_" element is present, it only manage it (ignores _MiningSchema_ fields)
> 2) if "_Output_" element is not present, it retrieves "_target_" from _MiningSchema_.
> This approach has the following issues
> 1) it is not mandatory to have the "_target/predicted_" field referenced inside the "_Output_" element; but with the current implementation, the user is "_forced_" to duplicate target reference inside "_Output_" if s/he wants additional outputs from model
> 2) it completely ignores "_Targets_" element
> With this PR, DMN will manage both the _Output_ elements (if present) and all the _target/predicted_ fields, regardless of where/how they are defined.
>
> If such _target/predicted_ fields is/are referred *also* in Output element, only the one(s) inside _Output_ will be managed.
> If _Output_ does not define "t_arget/predicted_" _OutputField_(s), the one(s) from _MiningSchema_ or _Targets_ will be managed.
>
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (DROOLS-5422) Fix DMN-PMML integration/managed fields
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5422?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5422:
-------------------------------------
Description:
>From [Output|[http://dmg.org/pmml/v4-4/Output.html]] documentation:
"If present, the attribute {{targetField}} must refer either to a {{MiningField}} of usage type {{target}} or a field described in {{Targets}} element. {{targetField}} is a required attribute in case the model has multiple target fields."
"predictedValue
Select the raw predicted value. More than one OutputField element can have the predictedValue feature only if the model predicts more than one field. Details can be found in the description of the individual models."
>From [MiningSchema|[http://dmg.org/pmml/v4-4/MiningSchema.html]] documentation:
"*predicted*: field whose value is predicted by the model. As of PMML 4.2, this is deprecated and it has been replaced by the usage type {{target}}."
So, _predicted_ field(s) is/are the one(s) defined as "_target/predicted_" inside _MiningSchema_ or the one(s) defined inside [Targets|[http://dmg.org/pmml/v4-4/Targets.html]] element.
Output have to be considered as _additional_ results; it does not _necessarily_ contains the _target/predicted_ value; *but* the _target/predicted_ value should always be returned.
Currently, DMN (see DMNKiePMMLInvocationEvaluator as example) implement the following algorithm:
1) if "_Output_" element is present, it only manage it (ignores _MiningSchema_ fields)
2) if "_Output_" element is not present, it retrieves "_target_" from _MiningSchema_.
This approach has the following issues
1) it is not mandatory to have the "_target/predicted_" field referenced inside the "_Output_" element; but with the current implementation, the user is "_forced_" to duplicate target reference inside "_Output_" if s/he wants additional outputs from model
2) it completely ignores "_Targets_" element
With this PR, DMN will manage both the _Output_ elements (if present) and all the _target/predicted_ fields, regardless of where/how they are defined.
If such _target/predicted_ fields is/are referred *also* in Output element, only the one(s) inside _Output_ will be managed.
If _Output_ does not define "t_arget/predicted_" _OutputField_(s), the one(s) from _MiningSchema_ or _Targets_ will be managed.
was:
>From [Output|[http://dmg.org/pmml/v4-4/Output.html]] documentation:
"If present, the attribute {{targetField}} must refer either to a {{MiningField}} of usage type {{target}} or a field described in {{Targets}} element. {{targetField}} is a required attribute in case the model has multiple target fields."
"predictedValue
Select the raw predicted value. More than one OutputField element can have the predictedValue feature only if the model predicts more than one field. Details can be found in the description of the individual models."
>From [MiningSchema|[http://dmg.org/pmml/v4-4/MiningSchema.html]] documentation:
"*predicted*: field whose value is predicted by the model. As of PMML 4.2, this is deprecated and it has been replaced by the usage type {{target}}."
So, predicted field(s) is/are the one(s) defined i"target/predicted" inside _MiningSchema_ or inside [Targets|[http://dmg.org/pmml/v4-4/Targets.html]] element.
Output have to be considered as _additional_ results; it does not _necessarily_ contains the _target/predicted_ value; *but* the _target/predicted_ value should always be returned.
Currently, DMN (see DMNKiePMMLInvocationEvaluator as example) implement the following algorithm:
1) if "_Output_" element is present, it only manage it (ignores _MiningSchema_ fields)
2) if "_Output_" element is not present, it retrieves "_target_" from _MiningSchema_.
This approach has the following issues
1) it is not mandatory to have the "_target/predicted_" field referenced inside the "_Output_" element; but with the current implementation, the user is "_forced_" to duplicate target reference inside "_Output_" if s/he wants additional outputs from model
2) it completely ignores "_Targets_" element
With this PR, DMN will manage both the _Output_ elements (if present) and all the _target/predicted_ fields, regardless of where/how they are defined.
If such _target/predicted_ fields is/are referred *also* in Output element, only the one(s) inside _Output_ will be managed.
If _Output_ does not define "t_arget/predicted_" _OutputField_(s), the one(s) from _MiningSchema_ or _Targets_ will be managed.
> Fix DMN-PMML integration/managed fields
> ---------------------------------------
>
> Key: DROOLS-5422
> URL: https://issues.redhat.com/browse/DROOLS-5422
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
>
> From [Output|[http://dmg.org/pmml/v4-4/Output.html]] documentation:
> "If present, the attribute {{targetField}} must refer either to a {{MiningField}} of usage type {{target}} or a field described in {{Targets}} element. {{targetField}} is a required attribute in case the model has multiple target fields."
> "predictedValue
> Select the raw predicted value. More than one OutputField element can have the predictedValue feature only if the model predicts more than one field. Details can be found in the description of the individual models."
> From [MiningSchema|[http://dmg.org/pmml/v4-4/MiningSchema.html]] documentation:
> "*predicted*: field whose value is predicted by the model. As of PMML 4.2, this is deprecated and it has been replaced by the usage type {{target}}."
>
> So, _predicted_ field(s) is/are the one(s) defined as "_target/predicted_" inside _MiningSchema_ or the one(s) defined inside [Targets|[http://dmg.org/pmml/v4-4/Targets.html]] element.
>
> Output have to be considered as _additional_ results; it does not _necessarily_ contains the _target/predicted_ value; *but* the _target/predicted_ value should always be returned.
>
> Currently, DMN (see DMNKiePMMLInvocationEvaluator as example) implement the following algorithm:
> 1) if "_Output_" element is present, it only manage it (ignores _MiningSchema_ fields)
> 2) if "_Output_" element is not present, it retrieves "_target_" from _MiningSchema_.
> This approach has the following issues
> 1) it is not mandatory to have the "_target/predicted_" field referenced inside the "_Output_" element; but with the current implementation, the user is "_forced_" to duplicate target reference inside "_Output_" if s/he wants additional outputs from model
> 2) it completely ignores "_Targets_" element
> With this PR, DMN will manage both the _Output_ elements (if present) and all the _target/predicted_ fields, regardless of where/how they are defined.
>
> If such _target/predicted_ fields is/are referred *also* in Output element, only the one(s) inside _Output_ will be managed.
> If _Output_ does not define "t_arget/predicted_" _OutputField_(s), the one(s) from _MiningSchema_ or _Targets_ will be managed.
>
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (DROOLS-5422) Fix DMN-PMML integration/managed fields
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-5422:
----------------------------------------
Summary: Fix DMN-PMML integration/managed fields
Key: DROOLS-5422
URL: https://issues.redhat.com/browse/DROOLS-5422
Project: Drools
Issue Type: Task
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
>From [Output|[http://dmg.org/pmml/v4-4/Output.html]] documentation:
"If present, the attribute {{targetField}} must refer either to a {{MiningField}} of usage type {{target}} or a field described in {{Targets}} element. {{targetField}} is a required attribute in case the model has multiple target fields."
"predictedValue
Select the raw predicted value. More than one OutputField element can have the predictedValue feature only if the model predicts more than one field. Details can be found in the description of the individual models."
>From [MiningSchema|[http://dmg.org/pmml/v4-4/MiningSchema.html]] documentation:
"*predicted*: field whose value is predicted by the model. As of PMML 4.2, this is deprecated and it has been replaced by the usage type {{target}}."
So, predicted field(s) is/are the one(s) defined i"target/predicted" inside _MiningSchema_ or inside [Targets|[http://dmg.org/pmml/v4-4/Targets.html]] element.
Output have to be considered as _additional_ results; it does not _necessarily_ contains the _target/predicted_ value; *but* the _target/predicted_ value should always be returned.
Currently, DMN (see DMNKiePMMLInvocationEvaluator as example) implement the following algorithm:
1) if "_Output_" element is present, it only manage it (ignores _MiningSchema_ fields)
2) if "_Output_" element is not present, it retrieves "_target_" from _MiningSchema_.
This approach has the following issues
1) it is not mandatory to have the "_target/predicted_" field referenced inside the "_Output_" element; but with the current implementation, the user is "_forced_" to duplicate target reference inside "_Output_" if s/he wants additional outputs from model
2) it completely ignores "_Targets_" element
With this PR, DMN will manage both the _Output_ elements (if present) and all the _target/predicted_ fields, regardless of where/how they are defined.
If such _target/predicted_ fields is/are referred *also* in Output element, only the one(s) inside _Output_ will be managed.
If _Output_ does not define "t_arget/predicted_" _OutputField_(s), the one(s) from _MiningSchema_ or _Targets_ will be managed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months