January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar

by Andrew Collins (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ] Andrew Collins updated DROOLS-1008: ----------------------------------- Description: General: When a kjar has a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup, regardless of settings.xml snapshot updatePolicy setting. Retrieving a new snapshot version is only possible through use of KieScanner.scanNow() or recycling the JVM, which will both fetch the new artifact from the remote repository and reload the kmodule in the KieServer JVM. Steps to reproduce: * KieServer and Business Central deployed to separate JVMs, pointing to independent maven repositories. Snapshot updatePolicy should be "always" in KieServer settings.xml. * Deploy new kjar snapshot from Business Central to remote artifactory. (unique version "1") * Start KieServer (verify new snapshot version is pulled from remote) * Deploy new kjar snapnshot. (unique version "2") Expected behavior: * Creating a new container, or invoking updateReleaseId() on existing container will pull latest snapshot from remote artifactory. Actual Behavior * Creating a new container, or invoking updateReleaseId() on existing container, does not query remote artifactory for latest snapshots. Workaround: * Forcing a KieScanner.scanNow() will fetch new snapshot from remote artifactory. * Or, restarting KieScanner JVM will fetch new snapshot from remote artifactory. was: Description of problem: When a kjar is a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup. Retrieving a new snapshot version is only possible through use of KieScanner.scanNow(), which will both fetch the new artifact from the remote repository, and reload the kmodule in the KieServer JVM. > KieServer to update container for SNAPSHOT kjar > ----------------------------------------------- > > Key: DROOLS-1008 > URL: https://issues.jboss.org/browse/DROOLS-1008 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 6.2.0.Final, 6.3.0.Final > Reporter: Andrew Collins > Assignee: Mario Fusco > Attachments: snapshot_kjar_reproducer.patch > > > General: > When a kjar has a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup, regardless of settings.xml snapshot updatePolicy setting. Retrieving a new snapshot version is only possible through use of KieScanner.scanNow() or recycling the JVM, which will both fetch the new artifact from the remote repository and reload the kmodule in the KieServer JVM. > Steps to reproduce: > * KieServer and Business Central deployed to separate JVMs, pointing to independent maven repositories. Snapshot updatePolicy should be "always" in KieServer settings.xml. > * Deploy new kjar snapshot from Business Central to remote artifactory. (unique version "1") > * Start KieServer (verify new snapshot version is pulled from remote) > * Deploy new kjar snapnshot. (unique version "2") > Expected behavior: > * Creating a new container, or invoking updateReleaseId() on existing container will pull latest snapshot from remote artifactory. > Actual Behavior > * Creating a new container, or invoking updateReleaseId() on existing container, does not query remote artifactory for latest snapshots. > Workaround: > * Forcing a KieScanner.scanNow() will fetch new snapshot from remote artifactory. > * Or, restarting KieScanner JVM will fetch new snapshot from remote artifactory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load

by Jose Cavieres (JIRA)

[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ] Jose Cavieres reopened DROOLS-987: ---------------------------------- There is nothing bad in that code. That same code is included in both jbpm 6 books and in the JBPM project: * This listener should be used to automatically fire rules as soon as they get activated. * Especially useful for executing business rule tasks as part of the process. https://github.com/droolsjbpm/jbpm/blob/6.3.x/jbpm-flow/src/main/java/org... See lines 82-83 Anyway, the problem doesn't disappear if you eliminate the listener and use fireUntilHalt(). In order to verify that, in RulesJUnitTest.java you just have to eliminate(or /* */) the lines 90-98 and eliminate the "//" in lines 135-136: //Disparador disp= new Disparador(); //disp.start(); Regards > Errors in Phreak under heavy and multi threaded load > ----------------------------------------------------- > > Key: DROOLS-987 > URL: https://issues.jboss.org/browse/DROOLS-987 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: linux > Java 7 > kernel 3.16 > Reporter: Jose Cavieres > Assignee: Marco Rietveld > Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz > > > Several threads are started, each one starts 1 jbpm process containing rule(s) task(s). > If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%. > Aparently the setFocus method used by rule tasks is related to the problem. > The most comon error is: > Caused by: java.lang.NullPointerException > at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141) > at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266) > at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361) > at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334) > at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317) > at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358) > at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6076) CLI deployment of WAR exploded JSF2.2 applications fails with exceptions

by Miroslav Pavleski (JIRA)

[ https://issues.jboss.org/browse/WFLY-6076?page=com.atlassian.jira.plugin.... ] Miroslav Pavleski commented on WFLY-6076: ----------------------------------------- The app expects its own security domain in standalone.xml: <security-domain name="timespent.security-domain" cache-type="default"> <authentication> <login-module code="Simple" flag="required"/> </authentication> </security-domain> > CLI deployment of WAR exploded JSF2.2 applications fails with exceptions > ------------------------------------------------------------------------ > > Key: WFLY-6076 > URL: https://issues.jboss.org/browse/WFLY-6076 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 10.0.0.CR5 > Reporter: Miroslav Pavleski > Assignee: Farah Juma > Attachments: app.zip, cli.log, console.log, other_console.log > > > In 9.0.2 FINAL and prior (8.1, 8.2) deploying an exploded WAR using the CLI was working fine. This kind of deployment has benefits during development as the static resources are updated on-save. > The problem occurs probably due JSF initialization, see the attachments. > Deployment using mvn wildfly:deploy works fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6076) CLI deployment of WAR exploded JSF2.2 applications fails with exceptions

by Miroslav Pavleski (JIRA)

[ https://issues.jboss.org/browse/WFLY-6076?page=com.atlassian.jira.plugin.... ] Miroslav Pavleski updated WFLY-6076: ------------------------------------ Attachment: other_console.log app.zip > CLI deployment of WAR exploded JSF2.2 applications fails with exceptions > ------------------------------------------------------------------------ > > Key: WFLY-6076 > URL: https://issues.jboss.org/browse/WFLY-6076 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 10.0.0.CR5 > Reporter: Miroslav Pavleski > Assignee: Farah Juma > Attachments: app.zip, cli.log, console.log, other_console.log > > > In 9.0.2 FINAL and prior (8.1, 8.2) deploying an exploded WAR using the CLI was working fine. This kind of deployment has benefits during development as the static resources are updated on-save. > The problem occurs probably due JSF initialization, see the attachments. > Deployment using mvn wildfly:deploy works fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6076) CLI deployment of WAR exploded JSF2.2 applications fails with exceptions

by Miroslav Pavleski (JIRA)

[ https://issues.jboss.org/browse/WFLY-6076?page=com.atlassian.jira.plugin.... ] Miroslav Pavleski commented on WFLY-6076: ----------------------------------------- I've tried to assemble stripped down version of the app (attached). Now it doesn't even deploy with mvn wildfly:deploy on 10CR5. Deploys on 9.0.2.Final. > CLI deployment of WAR exploded JSF2.2 applications fails with exceptions > ------------------------------------------------------------------------ > > Key: WFLY-6076 > URL: https://issues.jboss.org/browse/WFLY-6076 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 10.0.0.CR5 > Reporter: Miroslav Pavleski > Assignee: Farah Juma > Attachments: app.zip, cli.log, console.log, other_console.log > > > In 9.0.2 FINAL and prior (8.1, 8.2) deploying an exploded WAR using the CLI was working fine. This kind of deployment has benefits during development as the static resources are updated on-save. > The problem occurs probably due JSF initialization, see the attachments. > Deployment using mvn wildfly:deploy works fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1042) JavaDoc of StatelessKieSession should show usage of KieCommands (public API) instead of CommandFactory (internal-api)

by Duncan Doyle (JIRA)

Duncan Doyle created DROOLS-1042: ------------------------------------ Summary: JavaDoc of StatelessKieSession should show usage of KieCommands (public API) instead of CommandFactory (internal-api) Key: DROOLS-1042 URL: https://issues.jboss.org/browse/DROOLS-1042 Project: Drools Issue Type: Bug Components: docs Affects Versions: 6.4.0.Beta1 Reporter: Duncan Doyle Assignee: Duncan Doyle Priority: Trivial The StatelessKieSession's JavaDoc shows an example on how to use the API. However, the example shown in the doc uses the internal CommandFactory API instead of the new KieCommands API. We should not encourage users to use internal APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6021) Default transaction timeout is not applied for EJB bean when set for second time

by Fedor Gavrilov (JIRA)

[ https://issues.jboss.org/browse/WFLY-6021?page=com.atlassian.jira.plugin.... ] Fedor Gavrilov reassigned WFLY-6021: ------------------------------------ Assignee: Fedor Gavrilov (was: David Lloyd) > Default transaction timeout is not applied for EJB bean when set for second time > -------------------------------------------------------------------------------- > > Key: WFLY-6021 > URL: https://issues.jboss.org/browse/WFLY-6021 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Reporter: Ondřej Chaloupka > Assignee: Fedor Gavrilov > > It seems that transaction subsystem attribute {{default-timeout}} does not have any effect for EJB if it's redefined. It means if I set the default transaction timeout in transaction subystem for second (and next) time it's not applied for EJB beans. It's used the firstly set value. > The transaction timeout is not changed for EJB when server is reloaded. When server is restarted it refreshes all settings and EJB starts using the expected value for timeout settings. > If the value is read from subsystem > {{/subsystem=transactions:read-attribute(name=default-timeout)}} > it shows correct value (that one set for second time). But EJB seems not applying it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar

by Andrew Collins (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ] Andrew Collins updated DROOLS-1008: ----------------------------------- Description: Description of problem: When a kjar is a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup. Retrieving a new snapshot version is only possible through use of KieScanner.scanNow(), which will both fetch the new artifact from the remote repository, and reload the kmodule in the KieServer JVM. was:When a kjar is a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup. Updating a KieContainer to a newer snapshot version is only possible through use of the KieScanner, which will both fetch the new artifact from the remote repository, and reload the kmodule in the KieServer JVM. > KieServer to update container for SNAPSHOT kjar > ----------------------------------------------- > > Key: DROOLS-1008 > URL: https://issues.jboss.org/browse/DROOLS-1008 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 6.2.0.Final, 6.3.0.Final > Reporter: Andrew Collins > Assignee: Mario Fusco > Attachments: snapshot_kjar_reproducer.patch > > > Description of problem: > When a kjar is a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup. Retrieving a new snapshot version is only possible through use of KieScanner.scanNow(), which will both fetch the new artifact from the remote repository, and reload the kmodule in the KieServer JVM. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-13) Interoperability testing with KeyCloak

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-13?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse reassigned ELY-13: ----------------------------------- Assignee: Pedro Igor > Interoperability testing with KeyCloak > -------------------------------------- > > Key: ELY-13 > URL: https://issues.jboss.org/browse/ELY-13 > Project: WildFly Elytron > Issue Type: Sub-task > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Fix For: 1.1.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-19) Add KeyCloak based realm implementation.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-19?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse reassigned ELY-19: ----------------------------------- Assignee: Pedro Igor > Add KeyCloak based realm implementation. > ---------------------------------------- > > Key: ELY-19 > URL: https://issues.jboss.org/browse/ELY-19 > Project: WildFly Elytron > Issue Type: Sub-task > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Fix For: 1.1.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016