[JBoss JIRA] (DROOLS-1763) Dependent rule not firing
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1763?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1763:
-------------------------------------
In Drools 7 we enabled property reactivity by default http://docs.jboss.org/drools/release/7.3.0.Final/drools-docs/html_single/...
This feature is explained in more details here http://docs.jboss.org/drools/release/7.3.0.Final/drools-docs/html_single/...
Since your methods are called addX instead of setX Drools is not able in your case to figure out which property of your domain object is changed and then it doesn't propagate any change. If possible you can annotate your addX method of your beans to say which properties they affect. Otherwise you can explicitly say which property are changed using an update statement. If all this solutions are not reasonable for you, you can disable property reactivity either completely or only for that class. I strongly suggest to keep property reactivity on and use one of the other solution I advised if possible: we enabled property reactivity by default because it represent a good improvement both when writing rules and performance wise.
Please let me know if this worked for you otherwise I will investigate this issue further.
> Dependent rule not firing
> -------------------------
>
> Key: DROOLS-1763
> URL: https://issues.jboss.org/browse/DROOLS-1763
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.0.0.Beta7, 7.3.0.Final
> Environment: Linux all versions.
> JDK 1.8.0 Update 144
> Reporter: David Wade
> Assignee: Mario Fusco
> Attachments: 7.0.0.Beta6.txt, 7.3.0.Final.txt
>
>
> We have been using Drools since 2.x.
> Currently we use 7.0.0.Beta6 which works.
> We can't upgrade because since 7.0.0.Beta7 rules dependent on the consequence of another rule are not firing for some reason. This happens for us on 7.0.0.Beta7 through to 7.3.0.Final.
> Consider the following two rules. When run on 7.0.0.Beta6 both rules fire. From Beta7 through to 7.3.0.Final, only the SQ rule fire, despite the RC rule passing its conditions
> {code}
> rule "H2"
> salience -300
> when
> segment:SegmentWithTax(
> containsTax("SQ")
> , notContainsTax("H2", "RC")
> )
> then
> segment.addPercentageTaxEntry(taxCodeMap,"SQ","RC_13_PERCENT");
> end
> rule "SQ"
> when
> segment:SegmentWithTax(
> !containsTax("SQ")
> )
> then
> modify(segment) {
> addTaxEntry(taxCodeMap,"SQ_TRANSFER_TRANSIT_LESS_THAN_FOUR_HOURS")
> }
> end
> {code}
> Will attach Drools trace logging output * 2. One for [^7.0.0.Beta6.txt] , one for [^7.3.0.Final.txt] .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (DROOLS-1763) Dependent rule not firing
by David Wade (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1763?page=com.atlassian.jira.plugi... ]
David Wade commented on DROOLS-1763:
------------------------------------
Is there anything more I need to add here to progress this.
This seems a pretty critical failure to leave in current state.
> Dependent rule not firing
> -------------------------
>
> Key: DROOLS-1763
> URL: https://issues.jboss.org/browse/DROOLS-1763
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.0.0.Beta7, 7.3.0.Final
> Environment: Linux all versions.
> JDK 1.8.0 Update 144
> Reporter: David Wade
> Assignee: Mario Fusco
> Attachments: 7.0.0.Beta6.txt, 7.3.0.Final.txt
>
>
> We have been using Drools since 2.x.
> Currently we use 7.0.0.Beta6 which works.
> We can't upgrade because since 7.0.0.Beta7 rules dependent on the consequence of another rule are not firing for some reason. This happens for us on 7.0.0.Beta7 through to 7.3.0.Final.
> Consider the following two rules. When run on 7.0.0.Beta6 both rules fire. From Beta7 through to 7.3.0.Final, only the SQ rule fire, despite the RC rule passing its conditions
> {code}
> rule "H2"
> salience -300
> when
> segment:SegmentWithTax(
> containsTax("SQ")
> , notContainsTax("H2", "RC")
> )
> then
> segment.addPercentageTaxEntry(taxCodeMap,"SQ","RC_13_PERCENT");
> end
> rule "SQ"
> when
> segment:SegmentWithTax(
> !containsTax("SQ")
> )
> then
> modify(segment) {
> addTaxEntry(taxCodeMap,"SQ_TRANSFER_TRANSIT_LESS_THAN_FOUR_HOURS")
> }
> end
> {code}
> Will attach Drools trace logging output * 2. One for [^7.0.0.Beta6.txt] , one for [^7.3.0.Final.txt] .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-9479) SSL Resource Causing SSL is null
by Jason Bruwer (JIRA)
[ https://issues.jboss.org/browse/WFLY-9479?page=com.atlassian.jira.plugin.... ]
Jason Bruwer commented on WFLY-9479:
------------------------------------
Hi Stuart,
Were you able to re-produce the issue?
> SSL Resource Causing SSL is null
> --------------------------------
>
> Key: WFLY-9479
> URL: https://issues.jboss.org/browse/WFLY-9479
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Final
> Environment: Linux CentoOS with Docker.
> Reporter: Jason Bruwer
> Assignee: Stuart Douglas
> Attachments: Screen Shot 2017-10-27 at 09.57.26.png, Screen Shot 2017-10-31 at 14.42.57.png, Screen Shot 2017-10-31 at 14.43.35.png, back_to_TLS.png, nont_ssl_server.log, server_2017-10-27T05-58-24+0000.log, showcase-master.zip, web.xml, with_openssl_chrome_server.log, with_openssl_firefox_server.log
>
>
> 2017-10-25 13:28:42,865 ERROR [io.undertow.request] (default task-20) UT005023: Exception handling request to /fluid/javax.faces.resource/syntaxhighlighter.css.xhtml: java.lang.IllegalStateException: ssl is null
> at org.wildfly.openssl.SSLImpl.getSessionId0(Native Method)
> at org.wildfly.openssl.SSLImpl.getSessionId(SSLImpl.java:479)
> at org.wildfly.openssl.OpenSSLEngine.getSession(OpenSSLEngine.java:871)
> at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.getSession(ALPNLimitingSSLEngine.java:211)
> at io.undertow.protocols.ssl.SslConduit.getSslSession(SslConduit.java:638)
> at io.undertow.protocols.ssl.UndertowSslConnection.getSslSession(UndertowSslConnection.java:69)
> at io.undertow.protocols.http2.Http2Channel.getSslSession(Http2Channel.java:791)
> at io.undertow.server.protocol.http2.Http2SslSessionInfo.getCipherSuite(Http2SslSessionInfo.java:53)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:122)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2017-10-25 13:28:42,866 ERROR [io.undertow.request] (default task-32) UT005023: Exception handling request to /fluid/javax.faces.resource/layout/layout.css.xhtml: java.lang.IllegalStateException: ssl is null
> at org.wildfly.openssl.SSLImpl.getSessionId0(Native Method)
> at org.wildfly.openssl.SSLImpl.getSessionId(SSLImpl.java:479)
> at org.wildfly.openssl.OpenSSLEngine.getSession(OpenSSLEngine.java:871)
> at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.getSession(ALPNLimitingSSLEngine.java:211)
> at io.undertow.protocols.ssl.SslConduit.getSslSession(SslConduit.java:638)
> at io.undertow.protocols.ssl.UndertowSslConnection.getSslSession(UndertowSslConnection.java:69)
> at io.undertow.protocols.http2.Http2Channel.getSslSession(Http2Channel.java:791)
> at io.undertow.server.protocol.http2.Http2SslSessionInfo.getCipherSuite(Http2SslSessionInfo.java:53)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:122)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2017-10-25 13:28:42,865 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /fluid/javax.faces.resource/fa/font-awesome.css.xhtml: java.lang.IllegalStateException: ssl is null
> at org.wildfly.openssl.SSLImpl.getSessionId0(Native Method)
> at org.wildfly.openssl.SSLImpl.getSessionId(SSLImpl.java:479)
> at org.wildfly.openssl.OpenSSLEngine.getSession(OpenSSLEngine.java:871)
> at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.getSession(ALPNLimitingSSLEngine.java:211)
> at io.undertow.protocols.ssl.SslConduit.getSslSession(SslConduit.java:638)
> at io.undertow.protocols.ssl.UndertowSslConnection.getSslSession(UndertowSslConnection.java:69)
> at io.undertow.protocols.http2.Http2Channel.getSslSession(Http2Channel.java:791)
> at io.undertow.server.protocol.http2.Http2SslSessionInfo.getCipherSuite(Http2SslSessionInfo.java:53)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:122)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-5296) public final methods should be allowed for Local and Remote Business Interface View
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-5296?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski reassigned WFLY-5296:
------------------------------------
Assignee: Tomasz Adamski
> public final methods should be allowed for Local and Remote Business Interface View
> -----------------------------------------------------------------------------------
>
> Key: WFLY-5296
> URL: https://issues.jboss.org/browse/WFLY-5296
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 9.0.1.Final
> Reporter: Andreas Liebscher
> Assignee: Tomasz Adamski
>
> The spec says:
> Only public methods of the bean class (and any superclasses) may be invoked through the no-interface view. Attempted invocations of methods with any other access modifiers via the no-interface view reference must result in the javax.ejb.EJBException.
> So it is not allowed to use public final methods when using no-interface view.
> But WF-9.0.1-Final does also throw an exception when using local business interface view:
> ERROR [org.jboss.as.ejb3.invocation] (default task-31) WFLYEJB0034: EJB Invocation failed on component XxxBean for method public abstract yyy: javax.ejb.EJBException: java.lang.IllegalStateException: WFLYEE0067: Method does not exist public final zzz
> With WF-8.1.0-Final this was no problem!
> What has been changed in WF-9?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-9574) Distribution POSIX permissions not optimum
by Romain Pelisse (JIRA)
Romain Pelisse created WFLY-9574:
------------------------------------
Summary: Distribution POSIX permissions not optimum
Key: WFLY-9574
URL: https://issues.jboss.org/browse/WFLY-9574
Project: WildFly
Issue Type: Enhancement
Components: Build System
Affects Versions: 11.0.0.Final
Reporter: Romain Pelisse
Assignee: Romain Pelisse
Priority: Minor
The server provisioning copy (and extract) files in order to assemble the distribution based the information of the feature-pack. While doing so on a POSIX system, it keeps the permissions of the original files, which are not always optimum (see JBEAP-12374). For instance:
* .properties and .jar files are associated with the mask rw-rw-r-- giving access to it to any other and allowing group member to modify the file ;
* some directories like domain/tmp/auth have to restrictive mask like rwx------ that needs to be turned into rwxrwxr-x and other, likes domain have again a too permissive mask rwxrwxr-x (should be rwxr-xr-x).
On a "regular" Maven project, all of those changes could be specified in the assembly.xml, however in Wildfly cases, this is not really option because the provisioning-maven-plugin and feature-pack-build-maven-plugin are manipulating the content of the archive being built. Also, using assembly.xml would mean edit and update the 4 or 5 different assembly.xml in the project directory tree.
I plan thus to propose a fix for wildfly-build-tools to address all those (small) problems.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-9574) Distribution files does not have POSIX permissions perfectly set
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9574?page=com.atlassian.jira.plugin.... ]
Romain Pelisse updated WFLY-9574:
---------------------------------
Summary: Distribution files does not have POSIX permissions perfectly set (was: Distribution POSIX permissions not optimum)
> Distribution files does not have POSIX permissions perfectly set
> ----------------------------------------------------------------
>
> Key: WFLY-9574
> URL: https://issues.jboss.org/browse/WFLY-9574
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System
> Affects Versions: 11.0.0.Final
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
>
> The server provisioning copy (and extract) files in order to assemble the distribution based the information of the feature-pack. While doing so on a POSIX system, it keeps the permissions of the original files, which are not always optimum (see JBEAP-12374). For instance:
> * .properties and .jar files are associated with the mask rw-rw-r-- giving access to it to any other and allowing group member to modify the file ;
> * some directories like domain/tmp/auth have to restrictive mask like rwx------ that needs to be turned into rwxrwxr-x and other, likes domain have again a too permissive mask rwxrwxr-x (should be rwxr-xr-x).
> On a "regular" Maven project, all of those changes could be specified in the assembly.xml, however in Wildfly cases, this is not really option because the provisioning-maven-plugin and feature-pack-build-maven-plugin are manipulating the content of the archive being built. Also, using assembly.xml would mean edit and update the 4 or 5 different assembly.xml in the project directory tree.
> I plan thus to propose a fix for wildfly-build-tools to address all those (small) problems.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (DROOLS-2150) QuartzSchedulerService NullPointerException
by Csaba Házi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2150?page=com.atlassian.jira.plugi... ]
Csaba Házi updated DROOLS-2150:
-------------------------------
Steps to Reproduce:
I have an example rule with Complex Event Processing:
rule "more than 3 processes in 5 minutes"
when
Number(intValue > 3) from accumulate(
pie: ProcessInstanceEvent(
processId == "showcase_process",
state == ProcessInstance.STATE_ACTIVE)
over window:time(5m),
count(pie)
)
then
System.out.println("Send warning: " + drools.getRule().getName());
notifier.sendWarning(drools.getRule().getName());
end
When a new event is fired the QuartzSchedulerService tries to persist TimerJobInstance at
org.jbpm.process.core.timer.impl.QuartzSchedulerService.internalSchedule(TimerJobInstance) method. During serialization NotSerializableException occurs and call the internalSchedule(...) to create InmemoryTimerJobInstanceDelegate.
The cause of NotSerializableException: org.jbpm.persistence.timer.GlobalJPATimerJobFactoryManager.createTimerJobInstance(Job, JobContext, Trigger, JobHandle, InternalSchedulerService) SelfRemovalJob reference to org.drools.core.reteoo.ObjectTypeNode$ExpireJob that is not serializable unlike org.jbpm.process.instance.timer.TimerManager.ProcessJob.
Restart the apllication and Quartz loads triggers from database. When the trigger is fired I got NPE exception:
Caused by: java.lang.NullPointerException at org.jbpm.process.core.timer.impl.QuartzSchedulerService$InmemoryTimerJobInstanceDelegate.call(QuartzSchedulerService.java:401)
was:
I have an example rule with Complex Event Processing:
rule "more than 3 processes in 5 minutes"
when
Number(intValue > 3) from accumulate(
pie: ProcessInstanceEvent(
processId == "showcase_process",
state == ProcessInstance.STATE_ACTIVE)
over window:time(5m),
count(pie)
)
then
System.out.println("Send warning: " + drools.getRule().getName());
notifier.sendWarning(drools.getRule().getName());
end
When a new event is fired the QuartzSchedulerService tries to persist TimerJobInstance at
org.jbpm.process.core.timer.impl.QuartzSchedulerService.internalSchedule(TimerJobInstance) method. During serialization NotSerializableException occurs and call the internalSchedule(...) to create InmemoryTimerJobInstanceDelegate.
The cause of NotSerializableException: org.jbpm.persistence.timer.GlobalJPATimerJobFactoryManager.createTimerJobInstance(Job, JobContext, Trigger, JobHandle, InternalSchedulerService) SelfRemovalJob reference to org.drools.core.reteoo.ObjectTypeNode$ExpireJob that is not serializable.
Restart the apllication and Quartz loads triggers from database. When the trigger is fired I got NPE exception:
Caused by: java.lang.NullPointerException at org.jbpm.process.core.timer.impl.QuartzSchedulerService$InmemoryTimerJobInstanceDelegate.call(QuartzSchedulerService.java:401)
org.drools.core.reteoo.ObjectTypeNode.ExpireJob is not Serializable unlike org.jbpm.process.instance.timer.TimerManager.ProcessJob.
> QuartzSchedulerService NullPointerException
> -------------------------------------------
>
> Key: DROOLS-2150
> URL: https://issues.jboss.org/browse/DROOLS-2150
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Environment: jBPM 6 and Quartz timer
> Reporter: Csaba Házi
> Assignee: Mario Fusco
>
> 2017-11-23 10:52:11,064 INFO [org.quartz.core.JobRunShell] (JbpmScheduler_Worker-4) Job jbpm.Timer-ExpireJobContext-6 threw a JobExecutionException: : org.quartz.JobExecutionException: Exception when executing scheduled job [See nested exception: java.lang.NullPointerException]
> at org.jbpm.process.core.timer.impl.QuartzSchedulerService$QuartzJob.execute(QuartzSchedulerService.java:341)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:216)
> at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)
> Caused by: java.lang.NullPointerException
> at org.jbpm.process.core.timer.impl.QuartzSchedulerService$InmemoryTimerJobInstanceDelegate.call(QuartzSchedulerService.java:401)
> at org.jbpm.process.core.timer.impl.QuartzSchedulerService$InmemoryTimerJobInstanceDelegate.call(QuartzSchedulerService.java:348)
> at org.jbpm.process.core.timer.impl.QuartzSchedulerService$QuartzJob.execute(QuartzSchedulerService.java:322)
> ... 2 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (DROOLS-2150) QuartzSchedulerService NullPointerException
by Csaba Házi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2150?page=com.atlassian.jira.plugi... ]
Csaba Házi updated DROOLS-2150:
-------------------------------
Steps to Reproduce:
I have an example rule with Complex Event Processing:
rule "more than 3 processes in 5 minutes"
when
Number(intValue > 3) from accumulate(
pie: ProcessInstanceEvent(
processId == "showcase_process",
state == ProcessInstance.STATE_ACTIVE)
over window:time(5m),
count(pie)
)
then
System.out.println("Send warning: " + drools.getRule().getName());
notifier.sendWarning(drools.getRule().getName());
end
When a new event is fired the QuartzSchedulerService tries to persist TimerJobInstance at
org.jbpm.process.core.timer.impl.QuartzSchedulerService.internalSchedule(TimerJobInstance) method. During serialization NotSerializableException occurs and call the internalSchedule(...) to create InmemoryTimerJobInstanceDelegate.
The cause of NotSerializableException: org.jbpm.persistence.timer.GlobalJPATimerJobFactoryManager.createTimerJobInstance(Job, JobContext, Trigger, JobHandle, InternalSchedulerService) SelfRemovalJob reference to org.drools.core.reteoo.ObjectTypeNode$ExpireJob that is not serializable.
Restart the apllication and Quartz loads triggers from database. When the trigger is fired I got NPE exception:
Caused by: java.lang.NullPointerException at org.jbpm.process.core.timer.impl.QuartzSchedulerService$InmemoryTimerJobInstanceDelegate.call(QuartzSchedulerService.java:401)
org.drools.core.reteoo.ObjectTypeNode.ExpireJob is not Serializable unlike org.jbpm.process.instance.timer.TimerManager.ProcessJob.
was:
I have an example rule with Complex Event Processing:
rule "more than 3 processes in 5 minutes"
when
Number(intValue > 3) from accumulate(
pie: ProcessInstanceEvent(
processId == "showcase_process",
state == ProcessInstance.STATE_ACTIVE)
over window:time(5m),
count(pie)
)
then
System.out.println("Send warning: " + drools.getRule().getName());
notifier.sendWarning(drools.getRule().getName());
end
When a new event is fired the QuartzSchedulerService tries to persist TimerJobInstance at
org.jbpm.process.core.timer.impl.QuartzSchedulerService.internalSchedule(TimerJobInstance) method. During serialization NotSerializableException occurs and call the internalSchedule(...) to create InmemoryTimerJobInstanceDelegate.
The cause of NotSerializableException: org.jbpm.persistence.timer.GlobalJPATimerJobFactoryManager.createTimerJobInstance(Job, JobContext, Trigger, JobHandle, InternalSchedulerService) SelfRemovalJob reference to org.drools.core.reteoo.ObjectTypeNode$ExpireJob that is not serializable.
Restart the apllication and Quartz loads triggers from database. When the trigger is fired I got NPE exception:
Caused by: java.lang.NullPointerException at org.jbpm.process.core.timer.impl.QuartzSchedulerService$InmemoryTimerJobInstanceDelegate.call(QuartzSchedulerService.java:401)
> QuartzSchedulerService NullPointerException
> -------------------------------------------
>
> Key: DROOLS-2150
> URL: https://issues.jboss.org/browse/DROOLS-2150
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Environment: jBPM 6 and Quartz timer
> Reporter: Csaba Házi
> Assignee: Mario Fusco
>
> 2017-11-23 10:52:11,064 INFO [org.quartz.core.JobRunShell] (JbpmScheduler_Worker-4) Job jbpm.Timer-ExpireJobContext-6 threw a JobExecutionException: : org.quartz.JobExecutionException: Exception when executing scheduled job [See nested exception: java.lang.NullPointerException]
> at org.jbpm.process.core.timer.impl.QuartzSchedulerService$QuartzJob.execute(QuartzSchedulerService.java:341)
> at org.quartz.core.JobRunShell.run(JobRunShell.java:216)
> at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)
> Caused by: java.lang.NullPointerException
> at org.jbpm.process.core.timer.impl.QuartzSchedulerService$InmemoryTimerJobInstanceDelegate.call(QuartzSchedulerService.java:401)
> at org.jbpm.process.core.timer.impl.QuartzSchedulerService$InmemoryTimerJobInstanceDelegate.call(QuartzSchedulerService.java:348)
> at org.jbpm.process.core.timer.impl.QuartzSchedulerService$QuartzJob.execute(QuartzSchedulerService.java:322)
> ... 2 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months