[JBoss JIRA] (DROOLS-1423) KJAR changes are not reflected in KIE Container
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1423?page=com.atlassian.jira.plugi... ]
Edson Tirelli closed DROOLS-1423.
---------------------------------
Resolution: Rejected
Closing the ticket as it seems a mistake on the use of the engine. Re-open the ticket with additional information if you think otherwise.
> KJAR changes are not reflected in KIE Container
> -----------------------------------------------
>
> Key: DROOLS-1423
> URL: https://issues.jboss.org/browse/DROOLS-1423
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.5.0.Final
> Reporter: LakshmiNarayanan Kesavan
> Assignee: Edson Tirelli
>
> Step 1: Create a KJAR in Maven Repo with the DRL file and deploy the same in tomcat
> Step 2: Create the container
> Step 3: Execute the rule. The rule got successfully executed
> Step 4: Dispose the container. We get the below message
> 31-Jan-2017 14:50:13.001 INFO [http-nio-8000-exec-12] org.kie.server.services.jbpm.JbpmKieServerExtension.disposeContainer No container with id test_drl_nn_01_1 found
> 31-Jan-2017 14:50:13.002 INFO [http-nio-8000-exec-12] org.kie.server.services.impl.KieServerImpl.disposeContainer Container test_drl_nn_01_1 (for release id com.ge.hc.services.rs:test_drl_nn_01:1) successfully stopped
> Step 5: Try executing the rule. No container available hence the rule didnt get executed.
> Step 6: Modify the rule logic and create the new KJAR
> Step 7: Create container and we get the below message.
> 31-Jan-2017 15:01:44.333 WARNING [http-nio-8000-exec-10] org.kie.server.services.jbpm.ui.JBPMUIKieServerExtension.createContainer Unable to create image reference for container test_drl_nn_01_1 due to null
> 31-Jan-2017 15:01:44.334 INFO [http-nio-8000-exec-10] org.kie.server.services.impl.KieServerImpl.createContainer Container test_drl_nn_01_1 (for release id com.ge.hc.services.rs:test_drl_nn_01:1) successfully started
> Step 8: execute the rule.
> We observe the latest changes made to the rule logic is not reflecting in the container and only the old(OLD KJAR WITH OLD RULE LOGIC) contanier got created.
> This happens very sporadically and not always
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1423) KJAR changes are not reflected in KIE Container
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1423?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-1423:
---------------------------------------
>From the log snippet you pasted, it seems that you are creating the kjar with the same version all the time?
First container: com.ge.hc.services.rs:test_drl_nn_01:1
Second container: com.ge.hc.services.rs:test_drl_nn_01:1
If you do that, maven will not look inside the jar to detect differences. You must either increment the version number (recommended) or use a -SNAPSHOT suffix if you want maven to detect changes.
> KJAR changes are not reflected in KIE Container
> -----------------------------------------------
>
> Key: DROOLS-1423
> URL: https://issues.jboss.org/browse/DROOLS-1423
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.5.0.Final
> Reporter: LakshmiNarayanan Kesavan
> Assignee: Edson Tirelli
>
> Step 1: Create a KJAR in Maven Repo with the DRL file and deploy the same in tomcat
> Step 2: Create the container
> Step 3: Execute the rule. The rule got successfully executed
> Step 4: Dispose the container. We get the below message
> 31-Jan-2017 14:50:13.001 INFO [http-nio-8000-exec-12] org.kie.server.services.jbpm.JbpmKieServerExtension.disposeContainer No container with id test_drl_nn_01_1 found
> 31-Jan-2017 14:50:13.002 INFO [http-nio-8000-exec-12] org.kie.server.services.impl.KieServerImpl.disposeContainer Container test_drl_nn_01_1 (for release id com.ge.hc.services.rs:test_drl_nn_01:1) successfully stopped
> Step 5: Try executing the rule. No container available hence the rule didnt get executed.
> Step 6: Modify the rule logic and create the new KJAR
> Step 7: Create container and we get the below message.
> 31-Jan-2017 15:01:44.333 WARNING [http-nio-8000-exec-10] org.kie.server.services.jbpm.ui.JBPMUIKieServerExtension.createContainer Unable to create image reference for container test_drl_nn_01_1 due to null
> 31-Jan-2017 15:01:44.334 INFO [http-nio-8000-exec-10] org.kie.server.services.impl.KieServerImpl.createContainer Container test_drl_nn_01_1 (for release id com.ge.hc.services.rs:test_drl_nn_01:1) successfully started
> Step 8: execute the rule.
> We observe the latest changes made to the rule logic is not reflecting in the container and only the old(OLD KJAR WITH OLD RULE LOGIC) contanier got created.
> This happens very sporadically and not always
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-7946) Elytron ldap-realm does not handle loops in referrals
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7946?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7946:
--------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Elytron ldap-realm does not handle loops in referrals
> -----------------------------------------------------
>
> Key: WFLY-7946
> URL: https://issues.jboss.org/browse/WFLY-7946
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
> Attachments: print-roles.war
>
>
> According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".
> When application server is configured to use ldap-realm with dir-context which uses referral-mode=follow or throw and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server.
> [1] http://tools.ietf.org/html/rfc4511#section-4.1.10
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2250) CLI can exit although Aesh console has not been cleaned
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-2250:
--------------------------------------------
Summary: CLI can exit although Aesh console has not been cleaned
Key: WFCORE-2250
URL: https://issues.jboss.org/browse/WFCORE-2250
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
2 Threads. Thread1 is polling Aesh console status for its running state, as soon as the state is switched to !running, the CLI exists.
Ctrl-C is sent to CLI, Aesh command Thread initiates a shutdown, the CLI calls console.stop(). Aesh change running state to be false THEN does some cleanup. If thread1 is scheduled, then CLI exists although cleanup has not yet been operated. leaving an insane TTY.
The fix is to switch to Aesh 0.66.15 in which this bug has been fixed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1423) KJAR changes are not reflected in KIE Container
by LakshmiNarayanan Kesavan (JIRA)
LakshmiNarayanan Kesavan created DROOLS-1423:
------------------------------------------------
Summary: KJAR changes are not reflected in KIE Container
Key: DROOLS-1423
URL: https://issues.jboss.org/browse/DROOLS-1423
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 6.5.0.Final
Reporter: LakshmiNarayanan Kesavan
Assignee: Edson Tirelli
Step 1: Create a KJAR in Maven Repo with the DRL file and deploy the same in tomcat
Step 2: Create the container
Step 3: Execute the rule. The rule got successfully executed
Step 4: Dispose the container. We get the below message
31-Jan-2017 14:50:13.001 INFO [http-nio-8000-exec-12] org.kie.server.services.jbpm.JbpmKieServerExtension.disposeContainer No container with id test_drl_nn_01_1 found
31-Jan-2017 14:50:13.002 INFO [http-nio-8000-exec-12] org.kie.server.services.impl.KieServerImpl.disposeContainer Container test_drl_nn_01_1 (for release id com.ge.hc.services.rs:test_drl_nn_01:1) successfully stopped
Step 5: Try executing the rule. No container available hence the rule didnt get executed.
Step 6: Modify the rule logic and create the new KJAR
Step 7: Create container and we get the below message.
31-Jan-2017 15:01:44.333 WARNING [http-nio-8000-exec-10] org.kie.server.services.jbpm.ui.JBPMUIKieServerExtension.createContainer Unable to create image reference for container test_drl_nn_01_1 due to null
31-Jan-2017 15:01:44.334 INFO [http-nio-8000-exec-10] org.kie.server.services.impl.KieServerImpl.createContainer Container test_drl_nn_01_1 (for release id com.ge.hc.services.rs:test_drl_nn_01:1) successfully started
Step 8: execute the rule.
We observe the latest changes made to the rule logic is not reflecting in the container and only the old(OLD KJAR WITH OLD RULE LOGIC) contanier got created.
This happens very sporadically and not always
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2249) ObjectTypeValidator only validates fields the user provides
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2249:
----------------------------------------
Summary: ObjectTypeValidator only validates fields the user provides
Key: WFCORE-2249
URL: https://issues.jboss.org/browse/WFCORE-2249
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.0.0.Alpha23
This in ObjectTypeValidator is wrong:
{code}
@Override
public void validateParameter(final String parameterName, final ModelNode value) throws OperationFailedException {
super.validateParameter(parameterName, value);
if (value.isDefined()) {
for (String key : value.keys()) {
if (allowedValues.containsKey(key)) {
allowedValues.get(key).getValidator().validateParameter(key, value.get(key));
} else {
throw ROOT_LOGGER.invalidKeyForObjectType(key, parameterName);
}
}
}
}
{code}
1) It only iterates over the keys in 'value' so if value is missing any required fields that isn't detected.
2) It's not really appropriate to reject keys that are not part of the definition. The management code is meant to be forgiving in such cases.
For now I think I'll just focus on #1. It's debatable whether being forgiving is really ideal in general, and since this particular bit of unforgivingness has been around since at least 2012 I think I'll leave it alone.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8003) REST-AT bridge recovery test hanging because of missing client api
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-8003?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-8003:
--------------------------------
Comment: was deleted
(was: Downgrade of RestEASY may need us to revert https://issues.jboss.org/browse/JBTM-2714 ?)
> REST-AT bridge recovery test hanging because of missing client api
> ------------------------------------------------------------------
>
> Key: WFLY-8003
> URL: https://issues.jboss.org/browse/WFLY-8003
> Project: WildFly
> Issue Type: Bug
> Components: REST, Transactions
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Priority: Blocker
> Fix For: 11.0.0.Alpha1
>
>
> REST-AT bridge recovery test is hanging in all environments.
> It seems that the cause is a change in WildFly modules. Following errors appears in a test log:
> {code}
> c (finder: local module finder @5443d039 (roots: /Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> ^[[0m^[[31m11:32:31,304 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.ClientBuilder.newBuilder(ClientBuilder.java:103)
> ^[[0m^[[31m11:32:31,304 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.ClientBuilder.newClient(ClientBuilder.java:114)
> ^[[0m^[[31m11:32:31,304 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.synchronizeParticipantUrlWithCoordinator(RecoveryManager.java:239)
> ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.recreateParticipantInformation(RecoveryManager.java:202)
> ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.recoverParticipants(RecoveryManager.java:153)
> ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.registerDeserializer(RecoveryManager.java:62)
> ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.ParticipantsManagerImpl.registerDeserializer(ParticipantsManagerImpl.java:105)
> ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.<init>(InboundBridgeManager.java:60)
> ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.getInstance(InboundBridgeManager.java:50)
> ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeRecoveryModule.addBridgesToMapping(InboundBridgeRecoveryModule.java:164)
> ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeRecoveryModule.periodicWorkSecondPass(InboundBridgeRecoveryModule.java:109)
> ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811)
> ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) Caused by: java.lang.ClassNotFoundException: org.glassfish.jersey.client.JerseyClientBuilder from [Module "javax.ws.rs.api" from local module loader @a87f8ec (finder: local module finder @5443d039 (roots: /Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:200)
> ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
> ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
> ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at java.lang.Class.forName0(Native Method)
> ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at java.lang.Class.forName(Class.java:264)
> ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.FactoryFinder.newInstance(FactoryFinder.java:113)
> ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.FactoryFinder.find(FactoryFinder.java:206)
> ^[[0m^[[31m11:32:31,309 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.ClientBuilder.newBuilder(ClientBuilder.java:86)
> ^[[0m^[[31m11:32:31,309 ERROR [stderr] (Periodic Recovery) ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8003) REST-AT bridge recovery test hanging because of missing client api
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-8003?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-8003:
--------------------------------
Fix Version/s: 11.0.0.Alpha1
> REST-AT bridge recovery test hanging because of missing client api
> ------------------------------------------------------------------
>
> Key: WFLY-8003
> URL: https://issues.jboss.org/browse/WFLY-8003
> Project: WildFly
> Issue Type: Bug
> Components: REST, Transactions
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Priority: Blocker
> Fix For: 11.0.0.Alpha1
>
>
> REST-AT bridge recovery test is hanging in all environments.
> It seems that the cause is a change in WildFly modules. Following errors appears in a test log:
> {code}
> c (finder: local module finder @5443d039 (roots: /Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> ^[[0m^[[31m11:32:31,304 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.ClientBuilder.newBuilder(ClientBuilder.java:103)
> ^[[0m^[[31m11:32:31,304 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.ClientBuilder.newClient(ClientBuilder.java:114)
> ^[[0m^[[31m11:32:31,304 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.synchronizeParticipantUrlWithCoordinator(RecoveryManager.java:239)
> ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.recreateParticipantInformation(RecoveryManager.java:202)
> ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.recoverParticipants(RecoveryManager.java:153)
> ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.RecoveryManager.registerDeserializer(RecoveryManager.java:62)
> ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.integration.ParticipantsManagerImpl.registerDeserializer(ParticipantsManagerImpl.java:105)
> ^[[0m^[[31m11:32:31,305 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.<init>(InboundBridgeManager.java:60)
> ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.getInstance(InboundBridgeManager.java:50)
> ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeRecoveryModule.addBridgesToMapping(InboundBridgeRecoveryModule.java:164)
> ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at org.jboss.narayana.rest.bridge.inbound.InboundBridgeRecoveryModule.periodicWorkSecondPass(InboundBridgeRecoveryModule.java:109)
> ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811)
> ^[[0m^[[31m11:32:31,306 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) Caused by: java.lang.ClassNotFoundException: org.glassfish.jersey.client.JerseyClientBuilder from [Module "javax.ws.rs.api" from local module loader @a87f8ec (finder: local module finder @5443d039 (roots: /Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/Users/gytis/Workspace/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:200)
> ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)
> ^[[0m^[[31m11:32:31,307 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)
> ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at java.lang.Class.forName0(Native Method)
> ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at java.lang.Class.forName(Class.java:264)
> ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.FactoryFinder.newInstance(FactoryFinder.java:113)
> ^[[0m^[[31m11:32:31,308 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.FactoryFinder.find(FactoryFinder.java:206)
> ^[[0m^[[31m11:32:31,309 ERROR [stderr] (Periodic Recovery) at javax.ws.rs.client.ClientBuilder.newBuilder(ClientBuilder.java:86)
> ^[[0m^[[31m11:32:31,309 ERROR [stderr] (Periodic Recovery) ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months