[JBoss JIRA] (WFCORE-1857) Invalid operation shouldn't be completed at all
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-1857:
--------------------------------------------
Summary: Invalid operation shouldn't be completed at all
Key: WFCORE-1857
URL: https://issues.jboss.org/browse/WFCORE-1857
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
When an operation doesn't exist, the character ')' is added by completion although nothing should be proposed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7274) Undertow request failed HttpServerExchange due to replication timeout
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7274?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-6343 to WFLY-7274:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7274 (was: JBEAP-6343)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 10.1.0.Final
(was: 7.1.0.DR5)
> Undertow request failed HttpServerExchange due to replication timeout
> ---------------------------------------------------------------------
>
> Key: WFLY-7274
> URL: https://issues.jboss.org/browse/WFLY-7274
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Occured on server during eap-7x-failover-ejb-ejbservlet-shutdown-dist-async scenario.
> Server log stacktrace:
> {code}
> 15:29:15,717 WARN [org.jboss.weld.Servlet] (default task-104) WELD-000717: Unable to deactivate context org.jboss.weld.context.http.HttpSessionContextImpl@351bc717 when destroying request HttpServletRequestImpl [ GET /clusterbench/ejbservlet ]
> [JBossINF] 15:29:15,718 ERROR [io.undertow.request] (default task-104) UT005071: Undertow request failed HttpServerExchange{ GET /clusterbench/ejbservlet request {Cookie=[$Version=0; JSESSIONID=YiEdTzoqqzKiWxjI1VqEQNz8BB0id8L6GKrA1Uix.dev215; $Path=/clusterbench], Content-Length=[0], User-Agent=[Jakarta Commons-HttpClient/3.1], Host=[dev220:8080]} response {Set-Cookie=[JSESSIONID=YiEdTzoqqzKiWxjI1VqEQNz8BB0id8L6GKrA1Uix.dev213; path=/clusterbench], Content-Type=[text/html;charset=UTF-8], Content-Length=[80], Date=[Wed, 21 Sep 2016 19:29:00 GMT]}}: org.infinispan.util.concurrent.TimeoutException: Replication timeout for dev213
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:801)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:47)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:16)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Followed by:
> {code}
> 15:29:15,720 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread--p7-t17) ISPN000136: Error executing command LockControlCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on SessionCreationMetaDataKey(bprpzS1jzQGMjU9vmr1uwUvsN0ehaPpWtpRQYUhA) in behalf of transaction GlobalTransaction:<dev213>:108660:remote. Current owner GlobalTransaction:<dev213>:90576:remote.
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:261)
> ...
> {code}
> or:
> {code}
> 15:29:19,720 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-54) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on SessionCreationMetaDataKey(bprpzS1jzQGMjU9vmr1uwUvsN0ehaPpWtpRQYUhA) in behalf of transaction GlobalTransaction:<dev215>:112942:local. Current owner GlobalTransaction:<dev213>:90576:remote.
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:261)
> ...
> {code}
> Server logs:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1321) Prefer https over http for absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1321?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1321:
-------------------------------------
Description:
Motivation:
1) Chrome has "a long-term plan to mark all HTTP sites as non-secure."
https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
2) SEO: Google/Bing penalize website (lower ranking) that use http or mix http and https.
To do:
- Change all absolute links on our websites _and in our user manuals_ that lead to redhat.com, jboss.org, drools.org, optaplanner.org, jbpm.org and kiegroup.org to https.
- This includes canonical meta elements
- This includes tabzilla.js/.css loading of images (those actually give us the mixed https and http errors in chrome's inspect tooling if you go to https://www.drools.org today)
- This does not include external links, such as to wikipedia etc.
Keep an eye out on google webmaster tools to verify this doesn't introduce broken links.
Exceptions:
- ci.optaplanner.org must be on http, because those sites don't work over https...
Note: I've asked eng-ops to do ssl monitoring of our websites. So basically no risk of out of date certifications etc.
was:
Motivation:
1) Chrome has "a long-term plan to mark all HTTP sites as non-secure."
https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
2) SEO: Google/Bing penalize website (lower ranking) that use http or mix http and https.
To do:
- Change all absolute links on our websites _and in our user manuals_ that lead to redhat.com, jboss.org, drools.org, optaplanner.org, jbpm.org and kiegroup.org to https.
- This includes canonical meta elements
- This includes tabzilla.js/.css loading of images (those actually give us the mixed https and http errors in chrome's inspect tooling if you go to https://www.drools.org today)
- This does not include external links, such as to wikipedia etc.
Keep an eye out on google webmaster tools to verify this doesn't introduce broken links.
Exceptions:
- ci.optaplanner.org must be on http, because those sites don't work over https...
> Prefer https over http for absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
> ---------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1321
> URL: https://issues.jboss.org/browse/DROOLS-1321
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> Motivation:
> 1) Chrome has "a long-term plan to mark all HTTP sites as non-secure."
> https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
> 2) SEO: Google/Bing penalize website (lower ranking) that use http or mix http and https.
> To do:
> - Change all absolute links on our websites _and in our user manuals_ that lead to redhat.com, jboss.org, drools.org, optaplanner.org, jbpm.org and kiegroup.org to https.
> - This includes canonical meta elements
> - This includes tabzilla.js/.css loading of images (those actually give us the mixed https and http errors in chrome's inspect tooling if you go to https://www.drools.org today)
> - This does not include external links, such as to wikipedia etc.
> Keep an eye out on google webmaster tools to verify this doesn't introduce broken links.
> Exceptions:
> - ci.optaplanner.org must be on http, because those sites don't work over https...
> Note: I've asked eng-ops to do ssl monitoring of our websites. So basically no risk of out of date certifications etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1321) Prefer https over http for absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1321?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet edited comment on DROOLS-1321 at 10/7/16 7:04 AM:
-------------------------------------------------------------------
I've already done the change for optaplanner.org:
http://github.com/droolsjbpm/optaplanner-website/commit/3b25c74d6
http://github.com/droolsjbpm/optaplanner/commit/77ef50f00
Michael, if you can do similar changes for the other websites and user manuals, that would be great :)
was (Author: ge0ffrey):
I've already done the change for optaplanner.org:
http://github.com/droolsjbpm/optaplanner-website/commit/3b25c74d6
Michael, if you can do similar changes for the other websites and user manuals, that would be great :)
> Prefer https over http for absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
> ---------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1321
> URL: https://issues.jboss.org/browse/DROOLS-1321
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> Motivation:
> 1) Chrome has "a long-term plan to mark all HTTP sites as non-secure."
> https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
> 2) SEO: Google/Bing penalize website (lower ranking) that use http or mix http and https.
> To do:
> - Change all absolute links on our websites _and in our user manuals_ that lead to redhat.com, jboss.org, drools.org, optaplanner.org, jbpm.org and kiegroup.org to https.
> - This includes canonical meta elements
> - This includes tabzilla.js/.css loading of images (those actually give us the mixed https and http errors in chrome's inspect tooling if you go to https://www.drools.org today)
> - This does not include external links, such as to wikipedia etc.
> Keep an eye out on google webmaster tools to verify this doesn't introduce broken links.
> Exceptions:
> - ci.optaplanner.org must be on http, because those sites don't work over https...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7273) Adding ldap-realm in Elytron sometimes register capability even if add operation failed
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7273?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7273:
-----------------------------------
Affects Version/s: (was: 11.0.0.Alpha1)
> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-7273
> URL: https://issues.jboss.org/browse/WFLY-7273
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
> Fix For: 11.0.0.Alpha1
>
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7273) Adding ldap-realm in Elytron sometimes register capability even if add operation failed
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7273?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7273:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-7273
> URL: https://issues.jboss.org/browse/WFLY-7273
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
> Fix For: 11.0.0.Alpha1
>
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1318) Using java enum when setting a variable of type enum does not work
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1318?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1318.
---------------------------------
Resolution: Cannot Reproduce Bug
> Using java enum when setting a variable of type enum does not work
> ------------------------------------------------------------------
>
> Key: DROOLS-1318
> URL: https://issues.jboss.org/browse/DROOLS-1318
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.4.0.Final
> Reporter: Nicolas Heron
> Assignee: Mario Fusco
> Labels: OnBoarding
>
> In project https://github.com/chtiJBUG/onboarding-nautic-project
> when running the TestBirthday reduction
> TestBirthdayReduction : [Error: could not access/write property (seasonType) in: org.chtijbug.example.swimmingpool.Period] [Near :
> the source code of the rule is
> package org.training.leisure.swimmingpool;
> import java.lang.Number;
> import org.chtijbug.example.swimmingpool.CalculatedAttribute;
> import org.chtijbug.example.swimmingpool.Price;
> import org.chtijbug.example.swimmingpool.Person;
> import org.chtijbug.example.swimmingpool.Period;
> import org.chtijbug.example.swimmingpool.PriceType;
> rule "BirthdayReduction"
> dialect "mvel"
> ruleflow-group "reduction"
> when
> ccat : CalculatedAttribute( key == "IsPersonBirthday" , stringValue == "true" )
> pper : Person( calculatedAttributeList contains ccat , sprice : standardPrice > 0.0B )
> not (pprice : Price( description == "BirthdayReduction" ) and Person( priceList contains pprice , this == pper ))
> Period( seasonType == SeasonType.day )
> then
> Price nprice = new Price();
> nprice.setDescription( "BirthdayReduction" );
> nprice.setAmount( sprice.divide(new BigDecimal("10.0"),BigDecimal.ROUND_HALF_UP) );
> nprice.setPriceType( PriceType.promotion );
> insert( nprice );
> pper.addPrice( nprice );
> modify( pper ) {
> setPriceList( pper.getPriceList() )
> }
> end
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1318) Using java enum when setting a variable of type enum does not work
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1318?page=com.atlassian.jira.plugi... ]
Mario Fusco reassigned DROOLS-1318:
-----------------------------------
Assignee: Mario Fusco (was: Nicolas Heron)
> Using java enum when setting a variable of type enum does not work
> ------------------------------------------------------------------
>
> Key: DROOLS-1318
> URL: https://issues.jboss.org/browse/DROOLS-1318
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.4.0.Final
> Reporter: Nicolas Heron
> Assignee: Mario Fusco
> Labels: OnBoarding
>
> In project https://github.com/chtiJBUG/onboarding-nautic-project
> when running the TestBirthday reduction
> TestBirthdayReduction : [Error: could not access/write property (seasonType) in: org.chtijbug.example.swimmingpool.Period] [Near :
> the source code of the rule is
> package org.training.leisure.swimmingpool;
> import java.lang.Number;
> import org.chtijbug.example.swimmingpool.CalculatedAttribute;
> import org.chtijbug.example.swimmingpool.Price;
> import org.chtijbug.example.swimmingpool.Person;
> import org.chtijbug.example.swimmingpool.Period;
> import org.chtijbug.example.swimmingpool.PriceType;
> rule "BirthdayReduction"
> dialect "mvel"
> ruleflow-group "reduction"
> when
> ccat : CalculatedAttribute( key == "IsPersonBirthday" , stringValue == "true" )
> pper : Person( calculatedAttributeList contains ccat , sprice : standardPrice > 0.0B )
> not (pprice : Price( description == "BirthdayReduction" ) and Person( priceList contains pprice , this == pper ))
> Period( seasonType == SeasonType.day )
> then
> Price nprice = new Price();
> nprice.setDescription( "BirthdayReduction" );
> nprice.setAmount( sprice.divide(new BigDecimal("10.0"),BigDecimal.ROUND_HALF_UP) );
> nprice.setPriceType( PriceType.promotion );
> insert( nprice );
> pper.addPrice( nprice );
> modify( pper ) {
> setPriceList( pper.getPriceList() )
> }
> end
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1321) Prefer https over http for absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1321?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on DROOLS-1321:
------------------------------------------
I've already done the change for optaplanner.org:
http://github.com/droolsjbpm/optaplanner-website/commit/3b25c74d6
Michael, if you can do similar changes for the other websites and user manuals, that would be great :)
> Prefer https over http for absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
> ---------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1321
> URL: https://issues.jboss.org/browse/DROOLS-1321
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> Motivation:
> 1) Chrome has "a long-term plan to mark all HTTP sites as non-secure."
> https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
> 2) SEO: Google/Bing penalize website (lower ranking) that use http or mix http and https.
> To do:
> - Change all absolute links on our websites _and in our user manuals_ that lead to redhat.com, jboss.org, drools.org, optaplanner.org, jbpm.org and kiegroup.org to https.
> - This includes canonical meta elements
> - This includes tabzilla.js/.css loading of images (those actually give us the mixed https and http errors in chrome's inspect tooling if you go to https://www.drools.org today)
> - This does not include external links, such as to wikipedia etc.
> Keep an eye out on google webmaster tools to verify this doesn't introduce broken links.
> Exceptions:
> - ci.optaplanner.org must be on http, because those sites don't work over https...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (JGRP-2056) Measure latency for RPCs
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2056?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2056.
----------------------------
Resolution: Done
> Measure latency for RPCs
> ------------------------
>
> Key: JGRP-2056
> URL: https://issues.jboss.org/browse/JGRP-2056
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: bla.java, bla2.java
>
>
> Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
> * message bundlers at the sender and
> * message batch handling at the receiver
> This needs to be done for both requests and responses.
> Perhaps provide a way for callbacks to be invoked to measure the latency, e.g. request sent (dest, ID), response received (ID), so that tests like IspnPerfTest could collect them and create histograms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months