[JBoss JIRA] (DROOLS-1039) An invalid kie.conf should throw an exception and not be silently ignored
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1039?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet edited comment on DROOLS-1039 at 4/14/16 6:40 AM:
-------------------------------------------------------------------
I think it should fail fast, so it should throw an Exception, such as an IllegalStateException.
rantStart
Log messages can get lost (especially when deploying on app servers that ignore your logging config), are frequently ignored (too many projects start up with a dozen log messages, so that log message will scroll by in half a second, ...).
Crashing the app is a much better solution. It forces the developer to fix his stuff, immediately after he broke it, while he/she still remembers what he/she was doing. It doesn't allow it result to be judged as "assemblers don't work" (when the error message is burried in the log).
Frameworks that don't fail fast always have the same faith in large enterprise projects: they gather misconfigurations over time and they results/behaviour becomes suprising (as in incorrect) due to this misconfigurations. Users lose faith in them and even those the users are to blame for the misconfigurations, I believe the framework developers are too blame for allowing them to get away with it :)
rantEnd
was (Author: ge0ffrey):
I think it should fail fast, so it should throw an Exception, such as an IllegalStateException.
rantStart
Log messages can get lost (especially when deploying on app servers that ignore your logging config), are frequently ignored (too many projects start up with a dozen log messages, so that log message will scroll by in a few seconds, ...).
Crashing the app is a much better solution. It forces the developer to fix his stuff, immediately after he broke it, while he/she still remembers what he/she was doing. It doesn't allow it result to be judged as "assemblers don't work" (when the error message is burried in the log).
Frameworks that don't fail fast always have the same faith in large enterprise projects: they gather misconfigurations over time and they results/behaviour becomes suprising (as in incorrect) due to this misconfigurations. Users lose faith in them and even those the users are to blame for the misconfigurations, I believe the framework developers are too blame for allowing them to get away with it :)
rantEnd
> An invalid kie.conf should throw an exception and not be silently ignored
> -------------------------------------------------------------------------
>
> Key: DROOLS-1039
> URL: https://issues.jboss.org/browse/DROOLS-1039
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.4.0.Beta1
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> In drools-belief or optaplanner-core, change the META-INF/kie.conf file like this:
> {code}
> [
> 'assemblers' : [ new org.foo.ThisDoesNotExists() ],
> 'weavers' : [],
> 'runtimes' : [],
> 'beliefs' : []
> ]
> {code}
> Current behavior: it doesn't throw any exception, but of course later on things go haywire at some point with a completely unrelated error message.
> Expected Behavior: Fail fast and let me know that org.foo.ThisDoesNotExists does not exist and that my kie.conf is in error.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (SECURITY-934) RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-934?page=com.atlassian.jira.plug... ]
Romain Pelisse updated SECURITY-934:
------------------------------------
Git Pull Request: https://github.com/wildfly-security/jboss-negotiation/pull/29
> RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
> ---------------------------------------------------------------------------------------------
>
> Key: SECURITY-934
> URL: https://issues.jboss.org/browse/SECURITY-934
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Reporter: Hynek Švábek
> Assignee: Romain Pelisse
>
> There will be needless LDAP calls if we use AdvancedLdap login module.
> If a user is a member of (lets say) 100 groups, then we can get an extra 100 calls to the LDAP server.
> It can be performance problem.
> Same problem was in LdapExt login module.
> You can see this BZ https://bugzilla.redhat.com/show_bug.cgi?id=1223840
> https://issues.jboss.org/browse/SECURITY-891
> Example from Wireshark for 2 groups:
> {code}
> * searchRequest(3) "ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" wholeSubtree
> * searchResEntry(3) "CN=JBossAdmin,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResEntry(3) "CN=Slash/Char,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(3) success [2 results]
> * searchRequest(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
> * searchResEntry(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(4) success [1 result]
> * searchRequest(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
> * searchResEntry(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(5) success [1 result]
> {code}|
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1121) Run tests with different supported databases
by Petr Široký (JIRA)
Petr Široký created DROOLS-1121:
-----------------------------------
Summary: Run tests with different supported databases
Key: DROOLS-1121
URL: https://issues.jboss.org/browse/DROOLS-1121
Project: Drools
Issue Type: Task
Reporter: Petr Široký
Assignee: Petr Široký
Currently we only run tests with embedded H2 database, which is often not enough, because different databases do slightly different things and thus even if the code works on H2, it does not mean it will work on all supported databases.
We need to look into testing with multiple databases, preferably using Docker containers as that way we can make sure the databases are always in a clean state (as opposed to using shared DB instances).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (SECURITY-941) LdapExtLoginModule does not use empty string for rolesCtxDN search correctly
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/SECURITY-941?page=com.atlassian.jira.plug... ]
Ondrej Lukas updated SECURITY-941:
----------------------------------
Description: Using LdapExtLoginModule rolesCtxDN with empty string causes that no role search is done, i.e. no roles are assigned to user even if LDAP contains this mapping. In correct behavior empty string should be used as base DN of ldap search. It is regression against PicketBox 4.9.3.Final. (was: Using LdapExtLoginModule rolesCtxDN with empty string causes that no role search is done, i.e. no roles are assigned to user even if LDAP contains this mapping. In correct behavior empty string should be used as base DN of ldap search. It is regression against .
Issue is caused by fix of JBEAP-137. This issue was discovered during development of new regression tests for that issue.)
> LdapExtLoginModule does not use empty string for rolesCtxDN search correctly
> ----------------------------------------------------------------------------
>
> Key: SECURITY-941
> URL: https://issues.jboss.org/browse/SECURITY-941
> Project: PicketBox
> Issue Type: Bug
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Using LdapExtLoginModule rolesCtxDN with empty string causes that no role search is done, i.e. no roles are assigned to user even if LDAP contains this mapping. In correct behavior empty string should be used as base DN of ldap search. It is regression against PicketBox 4.9.3.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6520) LdapExtLoginModule does not use empty string for rolesCtxDN search correctly
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6520?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-6520:
-------------------------------
Description:
Using LdapExtLoginModule rolesCtxDN with empty string causes that no role search is done, i.e. no roles are assigned to user even if LDAP contains this mapping. In correct behavior empty string should be used as base DN of ldap search. It is regression against .
Issue is caused by fix of JBEAP-137. This issue was discovered during development of new regression tests for that issue.
was:
Using LdapExtLoginModule rolesCtxDN with empty string causes that no role search is done, i.e. no roles are assigned to user even if LDAP contains this mapping. In correct behavior empty string should be used as base DN of ldap search. It is regression against EAP 6.4.x.
Issue is caused by fix of JBEAP-137. This issue was discovered during development of new regression tests for that issue.
> LdapExtLoginModule does not use empty string for rolesCtxDN search correctly
> ----------------------------------------------------------------------------
>
> Key: WFLY-6520
> URL: https://issues.jboss.org/browse/WFLY-6520
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Using LdapExtLoginModule rolesCtxDN with empty string causes that no role search is done, i.e. no roles are assigned to user even if LDAP contains this mapping. In correct behavior empty string should be used as base DN of ldap search. It is regression against .
> Issue is caused by fix of JBEAP-137. This issue was discovered during development of new regression tests for that issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (SECURITY-941) LdapExtLoginModule does not use empty string for rolesCtxDN search correctly
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/SECURITY-941?page=com.atlassian.jira.plug... ]
Ondrej Lukas moved WFLY-6520 to SECURITY-941:
---------------------------------------------
Project: PicketBox (was: WildFly)
Key: SECURITY-941 (was: WFLY-6520)
Workflow: classic default workflow (was: GIT Pull Request workflow )
Component/s: (was: Security)
> LdapExtLoginModule does not use empty string for rolesCtxDN search correctly
> ----------------------------------------------------------------------------
>
> Key: SECURITY-941
> URL: https://issues.jboss.org/browse/SECURITY-941
> Project: PicketBox
> Issue Type: Bug
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Using LdapExtLoginModule rolesCtxDN with empty string causes that no role search is done, i.e. no roles are assigned to user even if LDAP contains this mapping. In correct behavior empty string should be used as base DN of ldap search. It is regression against .
> Issue is caused by fix of JBEAP-137. This issue was discovered during development of new regression tests for that issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6520) LdapExtLoginModule does not use empty string for rolesCtxDN search correctly
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-6520:
----------------------------------
Summary: LdapExtLoginModule does not use empty string for rolesCtxDN search correctly
Key: WFLY-6520
URL: https://issues.jboss.org/browse/WFLY-6520
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Critical
Using LdapExtLoginModule rolesCtxDN with empty string causes that no role search is done, i.e. no roles are assigned to user even if LDAP contains this mapping. In correct behavior empty string should be used as base DN of ldap search. It is regression against EAP 6.4.x.
Issue is caused by fix of JBEAP-137. This issue was discovered during development of new regression tests for that issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1039) An invalid kie.conf should throw an exception and not be silently ignored
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1039?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1039:
-------------------------------------
There's already a logged error message like:
{code}
2016-04-14 10:36:00,259 [main] ERROR Unable to build kie service url=file:/home/mario/workspace/droolsjbpm/drools/drools-beliefs/target/classes/META-INF/kie.conf reason=[Error: unable to resolve class: org.drools.beliefs.bayes.assembler.BayesAssemblerServicex]
[Near : {... assemblers' : [ new org.drools.beliefs.bayes.assem ....}]
^
{code}
and I'd prefer to keep it instead of throwing and Exception. What do you think?
> An invalid kie.conf should throw an exception and not be silently ignored
> -------------------------------------------------------------------------
>
> Key: DROOLS-1039
> URL: https://issues.jboss.org/browse/DROOLS-1039
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.4.0.Beta1
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> In drools-belief or optaplanner-core, change the META-INF/kie.conf file like this:
> {code}
> [
> 'assemblers' : [ new org.foo.ThisDoesNotExists() ],
> 'weavers' : [],
> 'runtimes' : [],
> 'beliefs' : []
> ]
> {code}
> Current behavior: it doesn't throw any exception, but of course later on things go haywire at some point with a completely unrelated error message.
> Expected Behavior: Fail fast and let me know that org.foo.ThisDoesNotExists does not exist and that my kie.conf is in error.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6519) bridge resource does not define a module for its transformer class
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6519?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-6519:
------------------------------
Description:
The bridge resource defines a transformer-class-name but there is no way to define which JBoss module contain this class.
This means that the module defining the class must be a dependency of the org.apache.activemq.artemis module since it's Artemis that currently loads it.
The messaging-activemq subsystem would then be able to load it and pass it to Artemis's ServiceRegistry (similarly to the interceptors).
was:
The divert resource defines a transformer-class-name but there is no way to define which JBoss module contain this class.
This means that the module defining the class must be a dependency of the org.apache.activemq.artemis module since it's Artemis that currently loads it.
The messaging-activemq subsystem would then be able to load it and pass it to Artemis's ServiceRegistry (similarly to the interceptors).
> bridge resource does not define a module for its transformer class
> ------------------------------------------------------------------
>
> Key: WFLY-6519
> URL: https://issues.jboss.org/browse/WFLY-6519
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> The bridge resource defines a transformer-class-name but there is no way to define which JBoss module contain this class.
> This means that the module defining the class must be a dependency of the org.apache.activemq.artemis module since it's Artemis that currently loads it.
> The messaging-activemq subsystem would then be able to load it and pass it to Artemis's ServiceRegistry (similarly to the interceptors).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6519) bridge resource does not define a module for its transformer class
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-6519:
---------------------------------
Summary: bridge resource does not define a module for its transformer class
Key: WFLY-6519
URL: https://issues.jboss.org/browse/WFLY-6519
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 10.0.0.Final
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
The divert resource defines a transformer-class-name but there is no way to define which JBoss module contain this class.
This means that the module defining the class must be a dependency of the org.apache.activemq.artemis module since it's Artemis that currently loads it.
The messaging-activemq subsystem would then be able to load it and pass it to Artemis's ServiceRegistry (similarly to the interceptors).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years