[JBoss JIRA] (WFLY-8309) build.sh and integration-tests.sh scripts doesn't work on Solaris SPARC
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/WFLY-8309?page=com.atlassian.jira.plugin.... ]
Frank Langelage commented on WFLY-8309:
---------------------------------------
This morning I tried build of WildFly 11.x first time on Solaris 10 and got this error mesage:
{noformat}
jboss@sb2000:/home/jboss/WildFly-11.0/wildfly ksh build.sh clean
/home/jboss/WildFly-11.0/wildfly/mvnw -Dmaven.user.home=/home/jboss/WildFly-11.0/wildfly/tools -s /home/jboss/WildFly-11.0/wildfly/tools/maven/conf/settings.xml clean
/home/jboss/WildFly-11.0/wildfly/mvnw: MAVEN_PROJECTBASEDIR=/home/jboss/WildFly-11.0/wildfly: is not an identifier
{noformat}
For me it was sufficient to simply do this change in mvnw:
{noformat}
-export MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
+MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
+export MAVEN_PROJECTBASEDIR
{noformat}
> build.sh and integration-tests.sh scripts doesn't work on Solaris SPARC
> -----------------------------------------------------------------------
>
> Key: WFLY-8309
> URL: https://issues.jboss.org/browse/WFLY-8309
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Test Suite
> Reporter: Peter Palaga
> Assignee: Romain Pelisse
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> Solaris 10 SPARC and Solaris 11 SPARC are supported platforms.
> This issue is regression against EAP 7.1.0.DR11.
> *Wrong behaviour in EAP 7.1.0.DR12*
> build.sh and integration-tests.sh scripts doesn't work on Solaris SPARC.
> *Desired behaviour*
> build.sh and integration-tests.sh scripts should work on Solaris SPARC.
> *Solaris 10*
> * Solaris 10 SPARC release information:
> {noformat}
> [hudson@dev139-03 ~]$ cat /etc/release
> Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC
> Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
> Assembled 17 January 2013
> [hudson@dev139-03 ~]$
> {noformat}
> * logs from build.sh
> {noformat}
> 07:39:36 + ./build.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/abacf11d/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dts.noSmoke
> 07:39:36 ./build.sh: syntax error at line 20: `DIRNAME="$( cd "$' unexpected
> {noformat}
> * logs from integration-tests.sh:
> {noformat}
> 07:43:10 + ./integration-tests.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.178.25 -Dnode1=10.16.178.26 -Dmcast=227.43.91.56 -DallTests -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/jboss-eap-7.1
> 07:43:10 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/mvnw install -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.178.25 -Dnode1=10.16.178.26 -Dmcast=227.43.91.56 -DallTests -fae -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/jboss-eap-7.1 -s /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/tools/maven/conf/settings.xml
> 07:43:10 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/mvnw: syntax error at line 190: `(' unexpected
> {noformat}
> *Solaris 11*
> * Solaris 11 SPARC release information:
> {noformat}
> [hudson@dev34-03 ~]$ cat /etc/release
> Oracle Solaris 11.3 SPARC
> Copyright (c) 1983, 2016, Oracle and/or its affiliates. All rights reserved.
> Assembled 03 August 2016
> [hudson@dev34-03 ~]$
> {noformat}
> * logs from build.sh
> {noformat}
> 07:39:35 + ./build.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dts.noSmoke
> 07:39:35 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/mvnw install '-Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/eap-local-maven-repository' '-fae' '-Dmaven.test.failure.ignore=true' '-Dts.noSmoke'
> 07:39:35 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/mvnw[190]: local: not found [No such file or directory]
> 07:39:35 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/mvnw[191]: local: not found [No such file or directory]
> 07:39:36 Error: Could not find or load main class org.apache.maven.wrapper.MavenWrapperMain
> {noformat}
> * logs from integration-tests.sh:
> {noformat}
> 7:43:15 + ./integration-tests.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.179.32 -Dnode1=10.16.179.33 -Dmcast=227.43.91.214 -DallTests -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/jboss-eap-7.1
> 07:43:15 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/mvnw install -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.179.32 -Dnode1=10.16.179.33 -Dmcast=227.43.91.214 -DallTests -fae -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/jboss-eap-7.1 -s /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/tools/maven/conf/settings.xml
> 07:43:15 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/mvnw[190]: local: not found [No such file or directory]
> 07:43:15 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/mvnw[191]: local: not found [No such file or directory]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFLY-7351) JAX-RS Http Client does not support SNI even though underlying Apache HttpClient version supports it
by R Searls (JIRA)
[ https://issues.jboss.org/browse/WFLY-7351?page=com.atlassian.jira.plugin.... ]
R Searls commented on WFLY-7351:
--------------------------------
App works in wildfly-11.0.0.Beta1-SNAPSHOT which is using resteasy 3.0.22.Final
App fails in wildfly-10.1.0.Final which is using resteasy 3.0.19.Final
> JAX-RS Http Client does not support SNI even though underlying Apache HttpClient version supports it
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-7351
> URL: https://issues.jboss.org/browse/WFLY-7351
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 10.1.0.Final
> Environment: N/A
> Reporter: Edvin Syse
> Assignee: Alessio Soldano
> Labels: httpclient, https, jax-rs
> Attachments: httpclient-sni-bug.zip
>
>
> When creating a JAX-RS client using ClientBuilder.newClient() and accessing an SSL resource configured with SNI, the request fails.
> When the request is made you get the default certificate for the ip as it is configured on the web server instead of the certificate corresponding to the host name you entered.
> Attached is a simple Maven project with a rest endpoint that will make a request to https://www.syse.no/, which is a host configured with SNI. If you access this host with a client that is not SNI capable, you will get the default certificate instead of the one corresponding to www.syse.no. (That cert is actually expired, so that is the underlying cause reported by the http client in this case. In other cases you will most probably just get a name mismatch type of error).
> This effectively prevents the Http client from being used reliably against a rapidly growing number of SSL enabled sites, as SNI is the new standard "everywhere" SSL is configured these days.
> The underlying Apache HttpClient version does indeed support SNI. I have tested the version of Apache HttpClient that is bundled with Wildfly 10.1 and it works correctly.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFLY-8517) ActiveMQ JGroups-based discovery is broken
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8517?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-10162 to WFLY-8517:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8517 (was: JBEAP-10162)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
JMS
(was: Clustering)
(was: JMS)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR15)
> ActiveMQ JGroups-based discovery is broken
> ------------------------------------------
>
> Key: WFLY-8517
> URL: https://issues.jboss.org/browse/WFLY-8517
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> JGroups-based discovery was broken by this commit:
> https://github.com/wildfly/wildfly/commit/b0244166a3a72aa891aa37ec7b0b866...
> {noformat}
> 2017-04-04 13:56:47,301 WARN [org.apache.activemq.artemis.core.client] (Thread-1 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@66462207-730663955)) AMQ212025: did not conne
> ct the cluster connection to other nodes: ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119013: Timed out waiting to receive cluster topology. Group:org.apache.activemq.artemis.co
> re.cluster.DiscoveryGroup@391e867]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:803)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:627)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:609)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl$5.run(ServerLocatorImpl.java:1533)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFLY-8516) Documentation in the XSD for the queue-length is incorrect based on the model description
by James Perkins (JIRA)
James Perkins created WFLY-8516:
-----------------------------------
Summary: Documentation in the XSD for the queue-length is incorrect based on the model description
Key: WFLY-8516
URL: https://issues.jboss.org/browse/WFLY-8516
Project: WildFly
Issue Type: Bug
Components: EE
Reporter: James Perkins
Assignee: James Perkins
The documentation for in the XSD for the {{queue-length}} on the {{managed-executor-service}} states:
{quote}
A managed executor service (implementing javax.enterprise.concurrent.ManagedExecutorService).
If the "thread-factory" attribute is not defined a managed thread factory with no context service and normal thread priority will be created and used by the executor.
The task queue is based on the values of "core-threads" and "queue-length":
* If "queue-length" is 0, or "queue-length" is Integer.MAX_VALUE (2147483647) and "core-threads" is 0, direct handoff queuing strategy will be used and a SynchronousQueue will be created.
* If "queue-length" is Integer.MAX_VALUE but "core-threads" is not 0, an unbounded queue will be used.
* For any other valid value for "queue-length", a bounded queue wil be created.
{quote}
The model description states:
{quote}
The executors task queue capacity. A length of 0 means direct hand-off and possible rejection will occur. An undefined length (the default), or Integer.MAX_VALUE, indicates that an unbounded queue should be used. All other values specify an exact queue size. If an unbounded queue or direct hand-off is used, a core-threads value greater than zero is required.
{quote}
The two descriptions should match. The model validation should also be checked as one of the messages doesn't seem to be correct:
{code:java}
// Validate an unbounded queue
if (!queueLength.isDefined() || queueLength.asInt() == Integer.MAX_VALUE) {
if (coreThreads.isDefined() && coreThreads.asInt() <= 0) {
throw EeLogger.ROOT_LOGGER.invalidCoreThreadsSize(coreThreads.asString());
}
}
{code}
That message doesn't really describe the real problem and will always be
{quote}
WFLYEE0112: The core-threads value must be greater than 0 when the queue-length is 0
{quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-1536) NPE thrown during application redeployment, slaves taken offline
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1536?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1536:
-------------------------------------------------
Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1406562|https://bugzilla.redhat.com/show_bug.cgi?id=1406562] from POST to MODIFIED
> NPE thrown during application redeployment, slaves taken offline
> ----------------------------------------------------------------
>
> Key: WFCORE-1536
> URL: https://issues.jboss.org/browse/WFCORE-1536
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Matthew Casperson
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha2
>
>
> We have some development Wildfly 10.0.0 servers running as slaves in a domain that frequently have WAR files redeployed. We have noticed that these slaves will often go offline after a redeployment of WAR files with the following stack trace:
> {code}
> 2016-05-06 05:05:51,306 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 1012) WFLYCTL0190: Step handler org.jboss.as.domain.controller.operations.deployment.DeploymentFullReplaceHandler@3f68226b for operation {"operation" => "full-replace-deployment","name" => "whatever.war","enabled" => true,"content" => [{"hash" => bytes { 0x5d, 0x12, 0x18, 0x2b, 0x1c, 0x86, 0x71, 0x27, 0x08, 0x3d, 0xf1, 0x75, 0x08, 0x29, 0xa6, 0x49, 0x1f, 0x16, 0xe8, 0x22 }}],"operation-headers" => {"access-mechanism" => "NATIVE","domain-uuid" => "802ab616-dd2c-4081-a79c-c4d54e14c384","push-to-servers" => undefined},"address" => [],"runtime-name" => undefined} at address [] failed handling operation rollback -- java.lang.NullPointerException: java.lang.NullPointerException
> at org.jboss.as.repository.LocalDeploymentFileRepository.deleteDeployment(LocalDeploymentFileRepository.java:59)
> at org.jboss.as.host.controller.RemoteDomainConnectionService$RemoteFileRepository.deleteDeployment(RemoteDomainConnectionService.java:756)
> at org.jboss.as.domain.controller.operations.deployment.DeploymentFullReplaceHandler$1.handleResult(DeploymentFullReplaceHandler.java:181)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 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 error will usually only happen for 2 out of the 4 identically configured slaves, and seems to happen randomly, although frequently enough.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (DROOLS-1130) Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES
by Pedro Almeida (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1130?page=com.atlassian.jira.plugi... ]
Pedro Almeida commented on DROOLS-1130:
---------------------------------------
[~mfusco], I've been trying to update my version from Drools 5.3.2 to the latest Drools version (6.5.0.Final) and I'm having the same problem as exposed in this issue. On Drools 5, the second rule would trigger, on Drools 6 it does not. If it's not a bug, is it a documented change ?
Cannot find nothing on this particular subject. Is there a way of triggering the fireAllRules at the end of each timer ?
Thanks.
> Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1130
> URL: https://issues.jboss.org/browse/DROOLS-1130
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Attachments: timer-rule-bug.zip
>
>
> I have a DRL file with 2 rules and the first rule has a timer of 3s, after this rule gets fired and a fact is modified, i expect a second rule to get activate and trigger but is not happening. Even though the documentation explicitly said in the 2.9.2 section of:
> http://docs.jboss.org/drools/release/6.3.0.Final/drools-docs/html/ch02.ht...
> _When the rule engine runs in passive mode (i.e.: using fireAllRules) by default it doesn't fire consequences of timed rules unless fireAllRules isn't invoked again. Now it is possible to change this default behavior by configuring the KieSession with a *TimedRuleExectionOption*_
> Please advise if i have misunderstood the expected behavior, attached is a demo project enclosing the mentioned rules and a testcase.
> *DRL:*
> {code}
> import java.util.logging.Logger
> import bug.timedrules.Table
> rule "table with 1 player"
> timer( int: 3s)
> no-loop true
> when
> $table : Table( getCounter() == 1)
> then
> Logger.getLogger("timer.drl").info("triggered - counter is 1");
> modify($table){
> setCounter(2)
> }
> end
> rule "Table upgrade to 2 player"
> no-loop true
> when
> $table : Table( getCounter() == 2)
> then
> Logger.getLogger("timer.drl").info("triggered - counter is 2");
> modify($table){
> setCounter(3)
> }
> end
> {code}
> *java code:*
> {code}
> @Test
> public void executeNewRuleAfterTimedRuleExecution() throws Exception {
> KieBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
> KieSessionConfiguration ksconf = KieServices.Factory.get().newKieSessionConfiguration();
> ksconf.setOption(TimedRuleExectionOption.YES);
> config.setOption(EventProcessingOption.STREAM);
> KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> final KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.add(ResourceFactory.newClassPathResource("bug/timer/timer.drl", BugTest.class), ResourceType.DRL);
> if (kbuilder.hasErrors()) {
> throw new IllegalStateException(kbuilder.getErrors().toString());
> }
> kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
> final StatefulKnowledgeSession statefulKnowledgeSession = kbase.newStatefulKnowledgeSession(ksconf, null);
> Table table = new Table(1234, 1);
> statefulKnowledgeSession.insert(table);
> statefulKnowledgeSession.fireAllRules();
> Thread.sleep(TimeUnit.SECONDS.toMillis(5));
> statefulKnowledgeSession.dispose();
> Assert.assertThat(table.getCounter(), CoreMatchers.is(3));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (ELY-1059) When I set iteration value as STRING or NEGATIVE integer then I get different error messages.
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1059?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1059:
----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> When I set iteration value as STRING or NEGATIVE integer then I get different error messages.
> ---------------------------------------------------------------------------------------------
>
> Key: ELY-1059
> URL: https://issues.jboss.org/browse/ELY-1059
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> When I set iteration value as STRING or NEGATIVE integer then I get different error messages rather the same one.
> {code}
> [hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar mask -x secret_password -s 12345678 --iteration="-123"
> ELY03025: Iteration count not specified for password based encryption
> [hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar mask -x secret_password -s 12345678 --iteration="ab123"
> java.lang.NumberFormatException: For input string: "ab123"
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (ELY-1058) When we set wrong ITERATION value (too big number or string) then we get NumberFormatException.
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1058?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1058:
----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> When we set wrong ITERATION value (too big number or string) then we get NumberFormatException.
> -----------------------------------------------------------------------------------------------
>
> Key: ELY-1058
> URL: https://issues.jboss.org/browse/ELY-1058
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> When we set wrong ITERATION value (too big number or string) then we get NumberFormatException.
> I expect here some meaningful message about what we expected -> e.g. integer value and its maximum value.
> {code}
> java -jar wildfly-elytron-tool.jar mask -x secret_password -i 2301145145644 -s 12用戶
> java.lang.NumberFormatException: For input string: "2301145145644"
> {code}
> {code}
> java -jar wildfly-elytron-tool.jar mask -x secret_password -i 230sd644 -s 12用戶
> java.lang.NumberFormatException: For input string: "230sd644"
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months