February 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13064) EJB client-side interceptor failure when using HTTPRemoting Protocol

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13064?page=com.atlassian.jira.plugi... ] Cheng Fang commented on WFLY-13064: ----------------------------------- [~f_marchioni] When did this test start to fail? > EJB client-side interceptor failure when using HTTPRemoting Protocol > -------------------------------------------------------------------- > > Key: WFLY-13064 > URL: https://issues.redhat.com/browse/WFLY-13064 > Project: WildFly > Issue Type: Bug > Components: EJB, Test Suite > Affects Versions: 19.0.0.Beta1 > Reporter: Francesco Marchioni > Assignee: Cheng Fang > Priority: Major > Attachments: surefire-reports-RemoteProtocolChangeClientInterceptorTestCase.zip > > > The following [test|https://github.com/wildfly/wildfly/blob/master/testsuite/integration...] fails in counting the EJB Client Interceptor count, when the HTTP Remoting Protocol is used: > {code:java} > @Test > @InSequence(2) > @OperateOnDeployment("client") > public void testHttpRemotingProtocol() throws Exception { > final Hashtable<String, String> props = new Hashtable<>(); > props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); > props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory"); > props.put(Context.PROVIDER_URL, "http-remoting://" + TestSuiteEnvironment.getServerAddress() + ":" > + (TestSuiteEnvironment.getHttpPort() + Integer.parseInt(getSystemProperty("jboss.socket.binding.port-offset", "100")))); > StatelessRemote bean = getRemote(new InitialContext(props)); > Assert.assertNotNull(bean); > // StatelessBean.methodCount field should equal 2 after second invoking (methodCount is a static field and is shared within a single JVM) > Assert.assertEquals(ProtocolSampleClientInterceptor.COUNT + 2, bean.method()); > } > {code} > Stack Trace: > {code:java} > 14:46:01 [ERROR] testHttpRemotingProtocol(org.jboss.as.test.multinode.clientinterceptor.protocol.RemoteProtocolChangeClientInterceptorTestCase) Time elapsed: 0.77 s <<< FAILURE! > 14:46:01 java.lang.AssertionError: expected:<12> but was:<11> > 14:46:01 at org.junit.Assert.fail(Assert.java:88) > 14:46:01 at org.junit.Assert.failNotEquals(Assert.java:834) > 14:46:01 at org.junit.Assert.assertEquals(Assert.java:645) > 14:46:01 at org.junit.Assert.assertEquals(Assert.java:631) > 14:46:01 at org.jboss.as.test.multinode.clientinterceptor.protocol.RemoteProtocolChangeClientInterceptorTestCase.testHttpRemotingProtocol(RemoteProtocolChangeClientInterceptorTestCase.java:130) > {code} > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4485) Support for multiple security realms - Distributed Identities

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-4485?page=com.atlassian.jira.plug... ] Darran Lofthouse updated WFCORE-4485: ------------------------------------- Fix Version/s: (was: 11.0.0.Beta9) > Support for multiple security realms - Distributed Identities > ------------------------------------------------------------- > > Key: WFCORE-4485 > URL: https://issues.redhat.com/browse/WFCORE-4485 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Priority: Major > Labels: CD17-Deferred, EAP-CD19, Previous_RFE > > By stacking LoginModules it was possible using PicketBox to attempt to authenticate using one remote store and if that failed try the next store in the list. > This RFE is to consider the use case where identities could be located across multiple stores and how they are aggregated together. > Additionally this use case should consider how the authorization information could be loaded from multiple sources and merged. > This RFE is not about fail over in the event of a realm being unavailable although it may be related. > This RFE is created as a result of comparing the differences between the PicketBox JAAS architecture and the Elytron architecture so I would not recommend this proceeds without some real world use cases identified. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5009) DMN Designer convert java class with invalid DMN identiefier

by Jozef Marko (Jira)

Jozef Marko created DROOLS-5009: ----------------------------------- Summary: DMN Designer convert java class with invalid DMN identiefier Key: DROOLS-5009 URL: https://issues.redhat.com/browse/DROOLS-5009 Project: Drools Issue Type: Bug Components: DMN Editor Affects Versions: 7.33.0.Final Reporter: Jozef Marko Assignee: Michael Anstis Attachments: Screenshot from 2020-02-05 16-21-10.png There is an issue if user convert java class to DMN data type while the java class contains field name, that is invalid identifier for DMN. for example assume this java class and try to convert it into DMN data type, you will get an error as attached. {code:java} public class Address { private int number; } {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5008) Implement tests for PMML in exec. server (nn, naive bayes, kmeans)

by Jiri Petrlik (Jira)

[ https://issues.redhat.com/browse/DROOLS-5008?page=com.atlassian.jira.plug... ] Jiri Petrlik updated DROOLS-5008: --------------------------------- Sprint: 2020 Week 04-06 (from Jan 20) > Implement tests for PMML in exec. server (nn, naive bayes, kmeans) > ------------------------------------------------------------------ > > Key: DROOLS-5008 > URL: https://issues.redhat.com/browse/DROOLS-5008 > Project: Drools > Issue Type: Task > Reporter: Jiri Petrlik > Assignee: Jiri Petrlik > Priority: Major > Labels: TrustyAI > > Implement tests for PMML in exec. server > * neural network > * naive bayes > * kmeans -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13064) EJB client-side interceptor failure when using HTTPRemoting Protocol

by Francesco Marchioni (Jira)

[ https://issues.redhat.com/browse/WFLY-13064?page=com.atlassian.jira.plugi... ] Francesco Marchioni updated WFLY-13064: --------------------------------------- Steps to Reproduce: {code:java} $ cd testsuite/integration/multinode $ mvn clean install -Dtest=*RemoteProtocolChangeClientInterceptorTestCase#testHttpRemotingProtocol -Djboss.dist=$JBOSS_HOME {code} was: {code:java} $ cd testsuite/integration/multinode $ mvn clean install -Dtest=*RemoteProtocolChangeClientInterceptorTestCase#testHttpRemotingProtocol -Djboss.dist=$JBOSS_HOME -Dsecurity.manager {code} > EJB client-side interceptor failure when using HTTPRemoting Protocol > -------------------------------------------------------------------- > > Key: WFLY-13064 > URL: https://issues.redhat.com/browse/WFLY-13064 > Project: WildFly > Issue Type: Bug > Components: EJB, Test Suite > Affects Versions: 19.0.0.Beta1 > Reporter: Francesco Marchioni > Assignee: Cheng Fang > Priority: Major > Attachments: surefire-reports-RemoteProtocolChangeClientInterceptorTestCase.zip > > > The following [test|https://github.com/wildfly/wildfly/blob/master/testsuite/integration...] fails in counting the EJB Client Interceptor count, when the HTTP Remoting Protocol is used: > {code:java} > @Test > @InSequence(2) > @OperateOnDeployment("client") > public void testHttpRemotingProtocol() throws Exception { > final Hashtable<String, String> props = new Hashtable<>(); > props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); > props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory"); > props.put(Context.PROVIDER_URL, "http-remoting://" + TestSuiteEnvironment.getServerAddress() + ":" > + (TestSuiteEnvironment.getHttpPort() + Integer.parseInt(getSystemProperty("jboss.socket.binding.port-offset", "100")))); > StatelessRemote bean = getRemote(new InitialContext(props)); > Assert.assertNotNull(bean); > // StatelessBean.methodCount field should equal 2 after second invoking (methodCount is a static field and is shared within a single JVM) > Assert.assertEquals(ProtocolSampleClientInterceptor.COUNT + 2, bean.method()); > } > {code} > Stack Trace: > {code:java} > 14:46:01 [ERROR] testHttpRemotingProtocol(org.jboss.as.test.multinode.clientinterceptor.protocol.RemoteProtocolChangeClientInterceptorTestCase) Time elapsed: 0.77 s <<< FAILURE! > 14:46:01 java.lang.AssertionError: expected:<12> but was:<11> > 14:46:01 at org.junit.Assert.fail(Assert.java:88) > 14:46:01 at org.junit.Assert.failNotEquals(Assert.java:834) > 14:46:01 at org.junit.Assert.assertEquals(Assert.java:645) > 14:46:01 at org.junit.Assert.assertEquals(Assert.java:631) > 14:46:01 at org.jboss.as.test.multinode.clientinterceptor.protocol.RemoteProtocolChangeClientInterceptorTestCase.testHttpRemotingProtocol(RemoteProtocolChangeClientInterceptorTestCase.java:130) > {code} > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5008) Implement tests for PMML in exec. server (nn, naive bayes, kmeans)

by Jiri Petrlik (Jira)

Jiri Petrlik created DROOLS-5008: ------------------------------------ Summary: Implement tests for PMML in exec. server (nn, naive bayes, kmeans) Key: DROOLS-5008 URL: https://issues.redhat.com/browse/DROOLS-5008 Project: Drools Issue Type: Task Reporter: Jiri Petrlik Assignee: Jiri Petrlik Implement tests for PMML in exec. server * neural network * naive bayes * kmeans -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5008) Implement tests for PMML in exec. server (nn, naive bayes, kmeans)

by Jiri Petrlik (Jira)

[ https://issues.redhat.com/browse/DROOLS-5008?page=com.atlassian.jira.plug... ] Jiri Petrlik updated DROOLS-5008: --------------------------------- Story Points: 3 > Implement tests for PMML in exec. server (nn, naive bayes, kmeans) > ------------------------------------------------------------------ > > Key: DROOLS-5008 > URL: https://issues.redhat.com/browse/DROOLS-5008 > Project: Drools > Issue Type: Task > Reporter: Jiri Petrlik > Assignee: Jiri Petrlik > Priority: Major > Labels: TrustyAI > > Implement tests for PMML in exec. server > * neural network > * naive bayes > * kmeans -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4978) Improve test coverage for PMML integration (nn, naive bayes, knn)

by Jiri Petrlik (Jira)

[ https://issues.redhat.com/browse/DROOLS-4978?page=com.atlassian.jira.plug... ] Jiri Petrlik commented on DROOLS-4978: -------------------------------------- Both PRs were merged: https://github.com/kiegroup/drools/pull/2739 https://github.com/kiegroup/kie-jpmml-integration/pull/21 > Improve test coverage for PMML integration (nn, naive bayes, knn) > ----------------------------------------------------------------- > > Key: DROOLS-4978 > URL: https://issues.redhat.com/browse/DROOLS-4978 > Project: Drools > Issue Type: Task > Components: core engine > Affects Versions: 7.33.0.Final > Reporter: Jiri Petrlik > Assignee: Jiri Petrlik > Priority: Major > Labels: TrustyAI > Fix For: 7.33.0.Final > > > Improve test coverage by testing more machine learning models: > * Naive Bayes > * Neural networks > * k-Nearest Neighbors -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2444) Remove ExecutionService

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2444?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2444. ---------------------------- Resolution: Done > Remove ExecutionService > ----------------------- > > Key: JGRP-2444 > URL: https://issues.redhat.com/browse/JGRP-2444 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0 > > > Nobody uses it -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2106) Prepare for JDK 11

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2106?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2106: --------------------------- Description: Investigate the changes needed to run with JDK 11. Probably module.info classes are all that's needed. Other things to investigate: * Replace {{Condition}} with {{Predicate}} * Remove {{FORWARD_TO_COORD}} was: Investigate the changes needed to run with JDK 11. Probably module.info classes are all that's needed. Other things to investigate: * Replace {{Condition}} with {{Predicate}} > Prepare for JDK 11 > ------------------ > > Key: JGRP-2106 > URL: https://issues.redhat.com/browse/JGRP-2106 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0 > > > Investigate the changes needed to run with JDK 11. Probably module.info classes are all that's needed. > Other things to investigate: > * Replace {{Condition}} with {{Predicate}} > * Remove {{FORWARD_TO_COORD}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2020