[JBoss JIRA] (JGRP-2043) Improve performance of Message#readHeader
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2043?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2043:
--------------------------------
This correlates with what Ralf observed in Munich: popupate ClassConfigurator map with {{id|Constructor}} pairs rather than {{id|Class}} pairs.
> Improve performance of Message#readHeader
> -----------------------------------------
>
> Key: JGRP-2043
> URL: https://issues.jboss.org/browse/JGRP-2043
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> A CPU hot spot highlighed by profiling via JFR:
> {noformat}Stack Trace Sample Count Percentage(%)
> java.lang.reflect.Constructor.newInstance(Object[]) 71 2.392
> java.lang.Class.newInstance() 71 2.392
> org.jgroups.Message.readHeader(DataInput) 71 2.392
> {noformat}
> I'd have expected the reflective constructor to perform well on a recent JVM, but apparently it's not in this case. A theory is that the {{Class}} type being unknown makes this code harder to optimise; needs to be looked into.
> It might be possible to patch the {{ClassConfigurator}} to provide instances of the required {{Header}} type rather than returning the class, and optimise that instead.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2042) Improve performance of Message#writeHeader
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2042?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2042:
---------------------------
Fix Version/s: 4.0
> Improve performance of Message#writeHeader
> ------------------------------------------
>
> Key: JGRP-2042
> URL: https://issues.jboss.org/browse/JGRP-2042
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> The following stacktrace, taken with JFR, is highlighting a CPU consumer which could be optimised.
> {noformat}Stack Trace Sample Count Percentage(%)
> java.util.IdentityHashMap.get(Object) 66 2.224
> org.jgroups.conf.ClassConfigurator.getMagicNumber(Class) 66 2.224
> org.jgroups.Message.writeHeader(Header, DataOutput) 66 2.224
> {noformat}
> One idea could be to use an ad-hoc implementation of Map which takes advantage of the key being a {{Class}}. An interesting alternative would be to avoid the map lookup altogether, by having the Header expose a method like "writeMagicNumber(DataInput to)".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2043) Improve performance of Message#readHeader
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2043?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2043:
---------------------------
Fix Version/s: 4.0
> Improve performance of Message#readHeader
> -----------------------------------------
>
> Key: JGRP-2043
> URL: https://issues.jboss.org/browse/JGRP-2043
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> A CPU hot spot highlighed by profiling via JFR:
> {noformat}Stack Trace Sample Count Percentage(%)
> java.lang.reflect.Constructor.newInstance(Object[]) 71 2.392
> java.lang.Class.newInstance() 71 2.392
> org.jgroups.Message.readHeader(DataInput) 71 2.392
> {noformat}
> I'd have expected the reflective constructor to perform well on a recent JVM, but apparently it's not in this case. A theory is that the {{Class}} type being unknown makes this code harder to optimise; needs to be looked into.
> It might be possible to patch the {{ClassConfigurator}} to provide instances of the required {{Header}} type rather than returning the class, and optimise that instead.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1379) service.bat points user to wrong directory
by Johannes Berggren (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1379?page=com.atlassian.jira.plugi... ]
Johannes Berggren commented on WFCORE-1379:
-------------------------------------------
This issue is in 10.0.0.Final. Moving the \service and \init.d directories to \bin creates the service successfully, but the service is unable to start. Windows displays the following error message:
Windows could not start the Wildfly on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 255.
The Windows System Events log says the following regarding the Wildfly service:
The Wildfly service terminated with the following service-specific error:
The extended attributes are inconsistent.
> service.bat points user to wrong directory
> ------------------------------------------
>
> Key: WFCORE-1379
> URL: https://issues.jboss.org/browse/WFCORE-1379
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 2.0.10.Final
> Reporter: Nicklas Karlsson
> Assignee: Tomaz Cerar
> Priority: Trivial
> Fix For: 3.0.0.Alpha1
>
>
> Running service.bat from the docs/contrib/scripts/service dir tells user to run the script under bin/service*s* but the binary paths to the services expects bin/service, resulting in service install failure with file not found
--
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 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:56 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 buried in the log).
Frameworks that don't fail fast, always have the same destiny in large enterprise projects: they gather misconfigurations over time and their results/behaviour become more and more surprising (= incorrect) due to these misconfigurations. Users lose faith in them and even though 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 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 buried in the log).
Frameworks that don't fail fast, always have the same destiny in large enterprise projects: they gather misconfigurations over time and they results/behaviour becomes surprising (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] (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:55 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 buried in the log).
Frameworks that don't fail fast, always have the same destiny in large enterprise projects: they gather misconfigurations over time and they results/behaviour becomes surprising (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 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 buried 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 surprising (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] (WFLY-6521) RolloutPlanTestCase fails with security manager
by Jan Tymel (JIRA)
Jan Tymel created WFLY-6521:
-------------------------------
Summary: RolloutPlanTestCase fails with security manager
Key: WFLY-6521
URL: https://issues.jboss.org/browse/WFLY-6521
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Jan Tymel
Assignee: Jan Tymel
*org.jboss.as.test.integration.domain.management.cli.RolloutPlanTestCase#testMaxFailServersPercentageRolloutPlan*
*org.jboss.as.test.integration.domain.management.cli.RolloutPlanTestCase#testMaxFailServersRolloutPlan*
*org.jboss.as.test.integration.domain.management.cli.RolloutPlanTestCase#testRollbackAcrossGroupsRolloutPlan*
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.domain -Dtest=org.jboss.as.test.integration.domain.suites.CLITestSuite -Dsecurity.manager}}
Fails with:
{code}
ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /RolloutPlanTestCase/RolloutServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost:8081" "listen,resolve")" in code source "(vfs:/content/RolloutPlanTestCase.war/WEB-INF/classes <no signer certificates>)" of "null")
[Server:main-one] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
[Server:main-one] at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
[Server:main-one] at java.lang.SecurityManager.checkListen(SecurityManager.java:1131) [rt.jar:1.8.0_71]
[Server:main-one] at org.wildfly.security.manager.WildFlySecurityManager.checkListen(WildFlySecurityManager.java:419)
[Server:main-one] at java.net.ServerSocket.bind(ServerSocket.java:374) [rt.jar:1.8.0_71]
[Server:main-one] at java.net.ServerSocket.bind(ServerSocket.java:329) [rt.jar:1.8.0_71]
[Server:main-one] at org.jboss.as.test.integration.domain.management.cli.RolloutPlanTestServlet.bind(RolloutPlanTestServlet.java:107) [classes:]
[Server:main-one] at org.jboss.as.test.integration.domain.management.cli.RolloutPlanTestServlet.processRequest(RolloutPlanTestServlet.java:66) [classes:]
[Server:main-one] at org.jboss.as.test.integration.domain.management.cli.RolloutPlanTestServlet.doGet(RolloutPlanTestServlet.java:94) [classes:]
[Server:main-one] at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
[Server:main-one] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar:1.0.0.Final-redhat-1]
[Server:main-one] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
[Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
[Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285) [undertow-servlet-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264) [undertow-servlet-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:181) [undertow-servlet-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_71]
[Server:main-one] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:178) [undertow-servlet-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792) [undertow-core-1.3.21.Final-redhat-1.jar:1.3.21.Final-redhat-1]
[Server:main-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_71]
[Server:main-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_71]
[Server:main-one] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_71]
{code}
--
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 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:54 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 buried 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 surprising (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 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
> 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] (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 commented on DROOLS-1039:
------------------------------------------
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